How to define a New Product for agile product development in a Startup



Moving Beyond Problem-Solution and Product-Market Fit

In the blog post “The Secret to commercializing an idea” i have reviewed the process of defining product features from idea to a marketable product. To quickly recap – the idea needs to be validated and packaged into a product that solves a real and acute problem for a group of a people. To do this you interview the target customers, analyze the competition and market environment. Market research leads to your unique value proposition – simply put, it is the single most important reason why customer buy from you. You start painting the portrait of your product and business model. A product is made up of its features, and all features are not equal. The business model is the details of how you create (ops, manufacturing etc), deliver (supply chain and distribution) and support (marketing, sales & customer service) products to generate profits.

Why you should prioritize and quantify the features that make up your product

The phase change from market research to product development phase should be a gradual and subtle change. There is no clear passing of a baton because your market research should include a lot of product features testing and the product development should have continuous customer feedback and testing integrated. But it is fair to say that there is a phase when the primary activity will shift from heavy focus on market research to product development. During this process of transitioning from planning to development the product features need to be crystalized in definition and direction. What this means is the product features should be quantified and prioritized and communicated in a way that the product development and marketing requirements are always in synch.

Product development team should understand without ambiguity on what to develop. For example, consider the example of a mobile phone team that is working on super long life battery as a feature. The quantitative description should be something like – “the battery should last for 40 hours between charges with an average use of 60 minutes of talk time and 150 minutes of data use”. As you can see, super-long life battery is something the development team cannot work with, does not help them in designing the batter or the phone circuitry.  But a specific description of the expected usage and time between charges is clear enough for the engineers to design the circuits and batter size. If this is the most important differentiator or the unique value proposition, the engineers have enough information to make the necessary tradeoffs to deliver the expected result.

It is not enough to quantify and prioritize the features – you also have to establish its sensitivity to market value

So, if you think quantitative description of the features sufficient? It is not. Consider the case the long battery life again. For argument sake let’s say the tradeoff for the long battery life is cost, driven by the electronic components and the battery technology selected. Consider the scenario that there is a shortage of a certain component that drives the cost up so much that getting the 40 hours battery life costs drives the cost beyond the limit of acceptable. So something would have to change. Is the project dead? Or can we compromise the cost or is 35 hours battery life acceptable? The answer lies in the market research and value proposition developed earlier. Since all features are not the same it is most likely that the one aspect can be compromised more than the other. Usually a predicament like this sets the product development team back in time lost as more analysis is required and a lot of communication goes back and forth in deciding the best course to pursue. But such situations are common and to be expected in the world of product development. So agile methods should prepare product development teams to better deal with tradeoffs and changing nature or deliverables.

One method to do this is with a MUSHCO requirements table. MUSHCO is our acronym for MUst have – SHould have – COuld have. This is a tool to communicate internally the DNA of the product. DNA – in the sense that the tool details of the composition of the features or building blocks of the product and its sensitivity to market needs. The features that are core to the value proposition are probably very important and the targets MUST be met for the product to succeed. Thus 35 hours between charges is a must have requirement. While Battery capacity, and max power and standby power consumption are should haves, in the sense that these enable the ‘Must have’. A SHOULD HAVE is what the product development team targets to achieve. Hence in the example below, Time between charges has a SHOULD HAVE value of 40 hours. This is what Engineering shoots for, but anything less than 15 hours puts the value proposition in jeopardy. But we are also saying that we ‘Could Have’ 48 hours between charges. This creates a WOW factor and would clearly give your product a big boost in end user adoption and could become a great differentiator. So if engineering COULD deliver this at an acceptable cost, then and only then, this is acceptable. But if other MUST HAVE’s are jeopardized to achieve 48 hours between charges then we should revert back to SHOULD HAVE value.

Noticed that not all rows need the Must, Should and Could columns filled in. This is because anything that is not core to customer value proposition will not be MUST HAVE and if an item is a basic functionality (commoditized), then it does not create a wow factor and it will not have a COULD HAVE.

Table 1 is an example of the MUSHCO for the battery life between charges.

Table 1 Must Have

Critical To Core Value Proposition – Cannot go to market without this

Should Have

Development Target –

Stretch Targets For Internal Teams

Could Have

Creates Wow or Significant Lead Over Competitors If Achieved

Time between charges Std. cond. (hours) 35 40 48
Capacity (WH) 600
Max. Power (W) 5.5
Standby Power (W) 0.4


Extending MUSHCO to tech startups

The above mentioned frame works very well when a product is being developed. But many technology startups do not have features such as battery life, or screen resolution etc. that can be meaningfully quantified. But there are significant internet startups and the same tool can be adapted with different interpretation of the MUSHCO. All features of a tech startup can be classified into MUSHCO framework and the MUST HAVE features will be the ones you validate first with the Minimum Viable Product (MVP). For every feature in a tech startup determine what is the minimum ‘functionality’ you MUST HAVE to meet your value promise. Then there is functionality you SHOULD HAVE soon after launch – before crossing the chasm. Your early adopters and enthusiasts see enough value in the MUST HAVE’s but the followers certainly will need more reasons to buy your product. So you SHOULD have it this ‘functionality’ soon after launch and certainly before the chasm. ‘Chasm’ refers to the leap a startup or new product has to make to go beyond the early adopters to mainstream customers. This is usually not a gradual transition but a step function. Once you have crossed the chasm you are likely to see steady growth or traction. All startups or new products COULD HAVE a reason or one thing about us that the customer remembers for a long time. It will likely be the first thing he tells his friends. We should capture the COULD HAVES as best as you can guess based on MVP testing and don’t forget to use your intuition along with customer research. Ideally, you should have a some MUST HAVE’s and a lot of SHOULD HAVES’s and very few COULD HAVE’s

See below an example of the MUSHCO for mobile site.

Table 2 MUSHCO example for mobile site

Table 2 Must Have

Critical To Core Value Proposition

Should Have

Needed to cross the Chasm

Could Have

Potential to go viral

Tools Functionality Edit/update/view

Personal view

Team view
Reports Yes
Team Management
Message YES


In table 2 we are communicating to the development team that the only important functionality required on mobile is the personal view/edit features for all the productivity tools. The team will try to implement the team views only if time and budget permits. Likewise the messaging feature is also not absolutely necessary but the team will try to achieve this. Team management row is unchecked which means this is a feature we are leaving out of this functionality on mobile phone app. We could have left it out completely but since this is a feature for tablets and web, I included in to explicitly communicate its omission. Reports on mobile is a feature that will probably thrill customers but it certainly is not core to the day to day updates required on mobile, hence it is a COULD HAVE.


Use the MUSHCO template to prioritize and quantify the sensitivity of the product features. This is an internal communication and guidance tool used to guide the product development team activity in sync with market requirements. It is likely that market requirements will change during the course of a project. More so with a startup than with an established product going through a revision. Unfortunately, changes can sometimes be viewed negatively, they are often associated with the connotation that marketing did not do their job? But if you have a competent team that has done its research well, it is still likely that the MUSHCO requirements have to be revised. This is reinforcement that your team is sensitive to recognize the need to change and adapt to customer requirements. This comes from continuous interaction with customers in meaningful ways. Change is good for the right reasons (certainly not an excuse for shoddy research). But MUSHCO should not be changed frequently and randomly. That will indicate a dysfunction of some kind (communication or research etc.). Changes should be made with the buy in of the team. Without buy-in there will not be accountability. Teams usually have mechanisms in place to review projects and get buy-in; these can be weekly team meetings in small startups or phase gate reviews in larger organizations. Make changes responsibly and communicate effectively. And decrease the time lost in miscommunication and lack of clarity. Experiment and see what works best for you, and do share and discus your experiences and learning. Whatever your experience is, I love to hear from you and connect – please do.


Leave a Reply

Your email address will not be published. Required fields are marked *