Discover more from Software Whisper
How To Decide What To Build Next For Your Digital Product?
Avoid wasting money, time, and talent and instead innovate more quickly than the competition
Hi there, it’s Niels. 🤗 Welcome to my newsletter. This newsletter helps with the creation of valuable software solutions, making better software investments, and improving the developer experience. Questions? Ask them here.
In April this year, I joined Sirris. Sirris is a not-for-profit organization that helps Belgian companies to achieve their innovation ambitions. This includes building innovations and helping them to adopt new innovations.
After 6 months, I’m starting to see patterns of what businesses struggle with. In this edition, I’m going to talk about one of the hot recurring topics that we help our customers with that are relatively new to building digital products.
What kind of businesses am I talking about exactly?
Businesses that are shifting from building digital solutions to digital products.
Businesses that are enhancing their physical product offering with digital product features.
Many of these businesses have trouble deciding what to build next and how to put together their product roadmap. This includes finding out which initiatives make sense to proceed with and how to prioritize the remaining ones.
They realize that poor decisions will lead to a waste of their resources including money, time, and talent. That’s also the time that they come to us for help.
At all times, you should avoid building products and features that no one wants (bad enough so that they want to pay for it).
What are the consequences for your resources when you do build products/features that no one cares about:
money: If no one wants to pay for your solution, your business will lose future revenue, and your investment to build it will be a sunk cost.
time: Your competition moves forward while your own business is moving backward. Your product becomes more cluttered with features no one wants.
talent: Your expensive software engineers are spending their talent building solutions that are not used. This will eventually lead to unhappy and unproductive employees. You even risk losing your engineers to other companies.
Keep on reading for an actionable step-by-step plan to prevent all these bad consequences from happening!
It will also help you to increase revenue, avoid sunk costs, and innovate more quickly with a happy and productive team of software engineers.
I want to stress that this article focuses on what to build next to increase customer value.
There are also other things to consider when developing products but these are not in scope for the remainder of this article: e.g. technical debt, internal process improvements, security issues, and legal issues.
Your goal should be to minimize the RISK of building something that no one wants bad enough. The risk is twofold:
There is a risk that your business solves the wrong problem.
Even when your business finds the right problem to solve, you might still invest huge resources in building the wrong solution.
It’s important to derisk both of them and increase your chance of successful investments.
Without a systematic plan, you are just a gambler. And as we all know: in the end, the house always wins.
Find The Right Problems
Explore and prioritize problems first to derisk investing in something no one cares about.
You should first have insight into what problems should be solved and for who exactly. The best way to find out is through interviews. These interviews will return qualitative data about what matters to the interviewees.
These interviews should answer the following questions:
Who are they?
Who are these different types of people exactly?
What identifies them, how do I recognize them, and what makes them different from other types of people?
What do these people do?
What jobs do they need to do? What problems do they have while doing it?
What jobs are most important to them, and what are their biggest struggles?
How are they doing their job now and what are the alternatives that they are using?
One of the biggest mistakes that you can make is to assume you know who the (potential) customers exactly are and what problems you should solve for them.
It’s important to define what a core market and an adjacent market are. This will help to better explain what kind of people you should interview.
A core market is defined as a group of people (the job executors or personas) plus the job they want to get done using your product.
An adjacent market is a market that includes either the current job executor or the current job that people want to get done, from the perspective of the company.
What people should you interview exactly and why?
Core market: discover the pain points with the existing product and features
Adjacent market: to gather information about related problems they face that aren’t covered by the product yet
Core market: to discover what they like/dislike about the alternatives to what your product is offering
Adjacent market: to discover what’s missing to apply your existing product to another type of job executor
If enough interviews happen, results should start to converge. If the results don’t converge, it might help to tune your customer interview and ask better or other questions.
It helps to create a screener for each type of customer. This is a question whose job is specifically to determine whether or not a given subject maps to a customer.
For each type of job executor, you should be able to gather the information depicted in the diagram underneath.
A persona is a synonym for job executor.
For the different types of job executors, you should be able to see:
job importance: what jobs matter the most to them and what do they care less about
job specific problems: a list of problems associated with executing that job
problem importance: how painful that problem is
Solving big problems creates a lot of value for customers and the business.
What do I mean by a big problem? A big problem is either:
a problem many job executors have
a very painful problem for a few job executors
something in-between the previous two
For the problems that do really exist, divide them into buckets based on their value. Try to keep it as simple as possible. I suggest using two different categories: High and Low
rank the high-value ones in descending order of value 👍
continue with the next step 👍
Low-value: deprioritize, revisit later or remove altogether 👎
Find The Right Solutions
From now on, it’s important to include the team that will be responsible for implementing the solution. This includes your designers and software engineers.
The product manager (or the person that is responsible for the product) can take the first stab at ideating a solution. Multiple solutions exist to solve the same problem. The goal is to select the best one. Other team members might come up with better ideas to solve this problem.
The goal is to come up with a solution that job executors prefer over what they are using now.
For existing customers, your solution should be an improvement compared to how they use your product now to get their job done.
Prospective customers from your core or adjacent market should be prepared to switch from what they are using now to your alternative.
You can’t simply ask a customer or prospect whether they’d like the product or feature you’re thinking of building. They’ll always say “yes”.
It’s the product manager’s job to select the best candidate solution to proceed.
The technical team should be able to estimate the implementation complexity for the solution. This includes the time it takes to implement, the technical challenge, and the development cost. Try to keep this process as simple and quick as possible. I suggest using T-shirt sizes: e.g. XL, L, M, S
The product manager can then map these to high or low complexity and make better priority decisions.
A value-complexity matrix is a great tool that helps you how to proceed with high-value problems. Remember that we already deprioritized low-value problems before.
high value, low complexity: easy win 👍
high value, high complexity: If possible, break these down into less complex tasks. 👍
Important here is that you should not always select easy wins at the expense of high-complexity solutions. You need to invest time in both. High-complexity items might be more innovative and return higher value in the long run.
High-complexity solutions should be derisked as much as possible. How to derisk them is dependent on the type of solution.
When moving into adjacent markets, it might make sense to create a new product while leveraging functionality that you already have in place.
This is the scenario where minimum viable products (MVPs) make sense. Most people think about the single-feature MVP when they hear the word MVP. But there are also other types of MVPs that might make sense for your specific scenario.
Using a low-fidelity MVP (which requires very minimal development) enables you to double-check the demand for your solution on a bigger scale than during the interviews.
The next step that you can take when the results are positive is to develop a high-fidelity MVP (which requires more development). This will show you how much customers are ready to pay for your product. It will also provide you with feedback about how to optimize your current solution.
Existing Product & Existing Job
Here it is important to verify if your solution is effectively an enhancement compared to the previous version. Rolling out this new version to all your customers at once would be a risky move.
Instead, you can roll out beta releases to only a small group of early adopters. This will result in useful feedback and it will make sure there are no major issues before releasing it to the general public.
Existing Product & New Job
This is a good moment to gauge if this product enhancement can be turned into a premium feature and how much they are prepared to pay for it.
Here we are somewhat in the middle of the previous two. If the complexity is high enough, both low-fidelity and high-fidelity MVPs might be of help. Rolling out beta releases to early adopters also makes sense.
Poor decisions about what to build next for your digital product will lead to nasty consequences for your business. My hope is by now, you have gained a better idea about deciding what to build next for your digital product to increase customer value.
I’ve explained how to find the most painful customer problems and prioritize what problems to solve first. It’s also important to take into account the complexity of a solution. For the best solution and the best outcome, great collaboration between team members is needed. Depending on the solution scenarios, MVPs or beta releases can help to derisk the outcome of a solution.
The next move is up to you! Do you want to increase your bottom line, innovate more quickly and forge a productive team of software engineers?
Don’t hesitate and contact me for tailored help that will boost your business!