Way of Working

What are some scoping best practices?

22 May 2020 • 13 minutes

Written by Jordi Kitto

Way of Working title image

A few of the key things you can do when scoping a product to ensure it hits the mark.

Starting a scope

Here at Codebots, we strongly believe in helping each company find their own Way of Working. From the battle hardened trenches of product design, we’ve come up with a few ‘activities’ you can do you ensure you don’t make the same mistakes we made early on. These are based on the Design Thinking Mindset, that you can read more about in our blog How can I use Design Thinking to scope products? But first, let me set the scene…

It’s a lazy Tuesday in the office and you’ve just finished treating yourself to a meal from the fancy burger shop up the road. A far cry from the one you and your team normally frequent. No, this one had hashbrowns on it! Just as you are starting to regret your decision to have a heavy lunch, one of your account managers comes over and tells you about a brand new project a client has come in for.

Brilliant! As your stomach churns, they tell you about this wild new idea they have. You don’t think it sounds particularly ground-breaking, just a simple update to their current system. Nevertheless, you head to the meeting the next day with the account manager, eager to get started.

As the client begins to explain all their problems, you start to get a better idea of their situation. Ideas form in your mind, and as soon as the meeting is over, it is time to get to work! Over the next few days or so, you’re whiteboarding and reading through all the documentation they client has provided.

Your team is happy with the result, and you all start designing up what you are going to build. The client seems to love the direction of your solution, and is eager to see it in action. A few weeks later, the first release is ready to go out to the users, and you all wait with bated breath for their response. A few days later, the client call you up, angrily listing all the complaints they have received from their users on the new system. “How could they not like it?”, you think to yourself, as the gut-wrenching realisation that you missed the mark completely hits you.

If you’ve ever found yourself in this situation, I can empathise with you! It was one I found myself in early in my career as a product designer. Coming into a field of web design, where the most important thing was how nice everything looked and if users could find the buttons on a page, it was quite a shock to the system to be in position where those were the things way down the list of things to consider.

As the User Experience (UX) role was still coming into existence outside of the most cutting edge of companies, it was here that I learnt the most important lesson about building products:

Listen to your users!

That project we worked on that missed the mark so completely could have been different if we had gone and listened to the users, and put them at the centre of what we were building. We have since learnt our lessons, and we’ve identified five activities you should always consider when scoping a project:

1. Discovery interviews

Interviewing people

One of the most important tasks you can do while starting out a new project, whether it be a whole new business idea of a modernisation of an old one, is actually sit down and talking with those who are going to be using it. Ground breaking, I know! Even in this day and age, I still regularly have to convince clients and development teams how important it is to just listen to the users.

I’ve been in my share of meetings where a client comes in and demands we do it exactly their way because a family friend told them it looked good. While they may be telling the truth, your family friend isn’t the one buying your product. Another issue is when development teams declare that they can substitute themselves as users because ‘they are users of software.’ Once again true, but those team still aren’t the ones who are going to be buying the product.

By shifting your mindset and hearing from your target users - all those people who aren’t financially or emotionally invested in a product - we get valuable data that we can use to support the users, not your mates down at the pub.

This one simple step at the start of a project helps clear away so much of the fog-of-war that teams face, providing clear patterns and evidence on what to build for. There is an article Activity: Discovery Interviews with more in-depth details on the importance and how to conduct interviews. Here are some of the key takeaways:

2. Defining the problem

Forming a solid understanding

Many a project and product can be derailed early on by not aligning the entire team to the central problem you’re all trying to solve. When the stakeholders are thinking one thing, the development is thinking something else and the users are thinking in a completely different direction, you’re never going to be able to build anything that works.

One of the earliest activities you can do is get your team along with the key stakeholders and define what the problem is you are all trying to solve. Design Thinking has you do this after speaking with your users, at Codebots we do it before and redefine after interviews. Do whatever way makes more sense for your Way of Working. Just do it early! I’ve written an article with more depth of Defining the problem and the different types they come in. Here are some key points to consider:

3. Brainstorming


While brainstorming is nothing new to most people, the way in which you do it may be. It is one of the most key activity sessions you can run while building a project as it is where truly creative and ingenious ideas are formed. What I learnt from Design Thinking and Jake Knapp’s Sprint book is how to run these sessions to maximise idea generation and squash stubbornness (results may vary.)

One of the best things about brainstorming is getting the entire team together to come up as many ideas as possible. And by whole team, I mean the WHOLE team. So many projects wind up being a couple of designers locked away in the backrooms going mad with power. A great project involves everyone, from those who are going to be building it, right up to the business owner who is investing in the product. I’ve written an article on how to brainstorm that you can read Brainstorming ideas. These are some key points:

4. Rapid prototyping

Building a rough prototype

This is one of the activities that I see done the least and normally done wrong by those who do it. It also one of the best and fastest ways to validate that the product you are trying to build is even going to be worth the time and investment to develop out. When people hear ‘prototype’ many people jump to ‘MVP’ which in turns jumps to ‘thing we are going to show our users.’ Then they quickly retreat back into their shell and demand that anything made and shown to users is 100% the best thing possible. Next thing you know it is months down the track and you just spent all that time making a dud.

The goal of rapid prototyping is to make something quick and dirty that either gets your idea, intent or concept across to users to see if they like it, test out if a piece of functionality is even possible or to try out a business workflow to see if people think it is worthwhile. Your users will understand if it doesn’t look well designed and sparkly. Just spend as little time as possible to test out the idea you have, and either adjust or start again with another idea if it failed.

I’ve written an article on what rapid prototyping is Rapid prototyping These are some key points:

5. User testing

Testing with users

As I said before, the best way to build products is by listening to your users. That’s why two of these five recommended activities are focused around just that. User testing is similar to discovery interviews in that your team is going out and learning more about those people outside your bubble. The difference is that this time you’re coming with a possible solution for them to try out.

Now you can watch them use your prototype to try and solve their problem. Did it work? Did they like it? How can we make this better? All questions that come out of these sessions and can quickly let you know if you’re onto a winning idea or if you need to go back to brainstorming. Maybe you’re just a little bit off and just need to change a few things. Either way you can get those valuable learnings to help guide the direction of the product. We’ve written an article on how to conduct user testing User Testing Here are some key points:


These five activities are just part of a larger series we’ve collected to help you craft products that put the user at the heart. It is important to remember that it is not how many or which ones you choose to do, you always need to keep testing it with people. It will ultimately result in far fewer projects that run off the rails and help keep everyone involved happy.

If you’d like to learn more about our Activity kit, where you can learn various methods to help start off a successful project, have a read of our ‘What is the Activity kit’ article.

Jordi Kitto

Written by Jordi Kitto

Software Developer

Jordi developed this very site you’re on right now! And when he’s not working on this site, he is showing off his latest Apple products to everyone in the office, or working on his side hustle