As a software founder you have to be a master of everything. You have to wake up with the motivation of Tony Robbins, morning routine of Elon Musk, run meetings like Bill Gates and finance like Jeff Bezos. It’s not easy. Yet, as a software founder, none of these skills and abilities are the number one skill that you absolutely have to have to be successful. That number one skill is

The ability to scope well

Or in other words, the ability to decide what features to do and what to leave out. This single ability alone can get you a software that you can afford to build and that people want and will pay for.

The good news is that this skill is something that can be learnt. Here are some guiding principles that can help:

The Pareto Principle

Way back in late 1800s an econnomist named Vilfredo Pareto came up with a simple idea:y 80% of the effects come from 20% of the causes. This is now known as the Pareto principle that gets quoted in every where people are trying to choose what to do and what to leave out.

It sounds too generic, too optimistic. Yet the funny thing is you’ll find over time it’s spot on. OK maybe not exactly 80% to the dot, but close enough. In the software context you could rephrase it as: 80% use of a software comes from just 20% of its features. So - if you could get to those 20% only you’d make most users happy. Think of the huge benefit, 20% of the costs (and time and effort) to get you enough of a software to go to market.

Another place in software where this 80-20 comes in is fixing bugs. Software will have bugs, but if you can find the right set of 20% bugs you can probably cover 80% of the issues. There’s a famous story (probably true) of Microsoft’s ex CEO Steve Balmer sending out an email about how this has clearly been proven by stats on bugs on Windows XP.

So be aware of the famous Mr. Pareto and learn to hone your skills for finding those magic 20% of what needs to be done.

The MoSCoW method

The MoSCoW analysis is a simple process for identifying priority items. It’s used to classify requirements into different groups according to their significance to the customer.

The process of MoSCoW analysis in software requirement analysis involves taking each possible requirement in your software and putting it into one of the following sets:

Must have : Something that must be done. Without it, it doesn’t make sense to release the product.
Should have: Something that should be done. You can live without this feature, but you risk losing a significant amount of customer interest if it’s missing.
Could have: Something that could be done. It’s a “nice to have” that makes the product better for your users, but at the same time it isn’t all that critical for your success.
Won’t have: Something that would be nice to have. If you’re done early, this is a nice, but really it’s neither required nor important to the majority of your customers.

Looking at these groups, you might think that such a grouping is something product management (or the product owner) could do on their own. But it’s really your job. Only you can see the full picture of time, effort, budget and time to market. The market (and your competitors) aren’t going to wait too long for your Must haves to be done. They’re going to move on. That’s why it’s important to do the MoSCoW analysis jointly between product management and engineering. If you can identify a Must have which isn’t feasible in a reasonable time-frame, you need to find alternatives, the sooner the better.

$100 test technique

This technique is described in the superb Managing software requirements (Leffingwell and Widrig) book. The idea is pretty simple:

Get all the major stakeholders in a prioritization session and then make a list of features/items that need to be prioritized.
Give everyone imaginary $100
Ask them to divide the amount among the given options (user stories, tasks, requirements).
Add up the dollars for each item once everyone is done and then you get to know which items are most valuable (and should be done first)

Five whys technique

The five whys method is part of the Toyota Production System. Developed by Sakichi Toyoda, the Japanese inventor. It’s the simplest thing on Earth, yet amazingly powerful in revealing hidden details of any problem. The process run by the analyst (usually you) asking the stakeholder (usually you again, so you asking yourself) repeatedly five times why the requirement is necessary until the importance of the requirements is clear. The answers reveal whether the requirement is really important or if can be delayed.

That’s it for today, if you really liked this and want to dig deeper, this is a hot bed of methods and techniques and recipes. Google and you’ll find a treasure trove. And if you want a superb book to read then the classics would be Agile Estimating and Planning by Mike Cohn and the aptly named Software by Numbers: Low-Risk, High-Return Development by Deene and Cleland-Huang