Getting the scope right is one of the biggest keys to success in your software development. That means transferring the ideas and concepts in your head down on paper so that a competent software developer can understand and implement them correctly.
There are two important things to get right here, which at first glance may seem to be contradictory.
- Be as specific as possible about the outcome required.
- Stay as open as possible about how that outcome will be achieved.
We’re looking for complete clarity at a reasonably granular level about what the software needs to do, but not so much technical instruction that the developer has no freedom to bring their expertise to the table and improve your vision of how it might work.
A good software team will consist of strategists, User Interface and User Experience Designers, Front end Developers, and Back end developers. Each brings a unique insight into the software development process and, with experience, study, and trial and error will have learnt patterns, workflows, and architecture that work well.
You are an expert in your own industry, but the chances are that you don’t have the same level of experience in developing software as a dedicated software studio. Beautiful synergy and innovation arise at the intersection between your industry experience and that of the development team. Pushing the technical specs too far into your domain, or pushing them too far into the development domain without bringing your own experience into it, too, will lead to an unbalanced relationship and an end result that isn’t as good as it could be.
This is the difference between software development houses or agencies and software development or digital product studios. An agency will need you to create a detailed list of features and a technical brief for them to work on. A studio will work with you to develop those things to achieve the optimal balance we’re talking about here.
To get clear on your scope, first, write down the assumption/s that you intend to prove. What are you assuming you’ll achieve if you build this software?
Here are some examples of assumptions:
“I assume that if I build a dashboard for my customers to show them the progress of the work I’m doing for them, they won’t phone into the business so often, so my call centre charges will be reduced.”
“I assume that providing an online system that takes customer orders and sends them straight to a sales and delivery portal will reduce turnaround time and free up my sales team to follow up on larger sales and build customer relationships.”
“I assume that if I build a portal that automates the majority of the process for creating contracts for my customers, it will allow me to scale without hiring more staff and free me up from a lot of the paperwork I do now.”
“If I provide all the key metrics for a specific industry in a single portal, it will be a valuable product to sell to my existing clients.”
Next, write down a list of the outcomes you intend to achieve. These will be in line with the assumptions you’ve just written.
For example:
- A customer dashboard that displays the status of orders for customers.
- A reports page that will allow your team to track and amend the status of orders.
- A portal that creates all the contracts and documents my clients need during a project.
- A dashboard that displays important metrics needed for running a business in a particular industry
Now that you have a definite set of outcomes, write the list of features you’ll need to achieve those specific outcomes
- A customer login so that customer data is secure and private
- A customer dashboard that displays the following items:
- Current orders
- The current status of each current order
- A page for each customer order showing notes and progress of that order, with current status and estimated delivery date.
- A team area to manage order details and statuses
- An email notification piece that sends each customer an email when the status of an order is changed.
The main task here is to ensure that each of your features directly contributes to the core outcome, and will work towards proving that original assumption. Anything that is a ‘nice to have’ that might be cool or fun or elegant but doesn’t directly contribute to providing or disproving the original assumption should be placed to the side, in a backlog, for the first version of your software.
Following this process is how you define your Minimum Viable Product, or MVP. This keeps you focused, and allows you to build something lean but perfectly formed to try out the idea before building a huge piece of software that nobody can use for a reason that you didn’t foresee upfront.
Most business leaders are visionaries, and so this process is usually challenging; “now that I’ve thought of this feature, it needs to be in the MVP” is a common statement.
Take a moment to check this when you think of a new feature. Check out your original list of outcomes. Will this new feature actively contribute to your intended outcome, and more importantly, is this outcome not achievable if it’s not included?
You can be a little relaxed about your first list of features for the MVP - assuming you’re working with an Agile development team (and you should be). this list isn’t written in stone and will most definitely change as you learn more about the application during development.
Working in this way ensures you’re always clear about what you need to achieve and why each feature is essential to the project's success. It’s also the best method I’ve found for reducing that curse of software projects; scope creep. Scope creep is when you keep adding new features to the project before it’s released; this usually happens when there’s not enough attention applied to the initial assumptions and outcomes, or the feature list is too vague and not kept strictly to the list of assumptions and outcomes.
Keeping to the scope is much harder than you might realise. When you’re in the midst of a software project, it can be exciting; features are being delivered, you’re seeing new interfaces for the first time, and everyone you show the work in progress to has an idea for another feature that could level it up.
All of these views are valid, but they can knock you off-piste very quickly, and the focus of the project can slip, along with deadlines and budgets, if you don’t stick to the method I’ve outlined here - with each new feature idea, as the same questions - is it essential to prove the assumption, and can we achieve the intended outcome without it at this point?
I’m not advising you to build anything half-baked, remember. The MVP should be functional, reliable, usable, and beautiful. It should only include the features you need to achieve the outcomes the software was built for, and your team should always build the most important items first. Working in this way allows you to ship as early as possible to get real-world feedback on what you’re building.
And then, repeat.
A good product studio can take your list of features and use its expertise to turn it into a technical brief for the developers. A brief that takes into account the lessons of past projects, the abilities of the development team, and the latest practices and breakthroughs in the world of software development that the project might be able to take advantage of.
Use that, and watch your idea fly.
