Our primary focus is to figure out how to increase Value to User. As mentioned in Define Needs, this is not the only things we build – but it is the primary thing.
No matter if we our goal is to increase Value to User, decrease cost or improve the Flow of Value, we are always striving to do the smallest thing that can possible work and then learning and adapting based on the result. This can’t be mentioned enough, since the vast majority of teams do not yet have this absolute focus in their mindset.
This is true no matter where we are in the Customer Development cycle. When we are in Growth we still need to figure out what the smallest thing that can help a User solve a need is. The same goes for the other types of needs. And most of the time we will not know for sure if our solution works until we have proper feedback from the Users (see Learn from Users).
We need to consider what the problem we are trying to solve is and our hypothesis for a good way of solving it.
If we are reasonably sure we understand the problem and a solution we can go ahead and build the smallest thing that solves the problem. This can for example be the case if our competitors have already solved the problem and users are asking us for a similar solution – and it is pretty straightforward. Of course we would prefer building something better, but some things really are easy and straightforward so we might want those done quickly and spend more time on features where we can really differentiate our product.
Sometimes we are not sure we fully understand the problem after discussing it with users. Or how to solve the problem in the best way. Rather than only spending time in lots of discussions it is usually much more efficient to create a prototype that can visualize and improve understanding of both the problem and potential solutions. Sometimes when you show a prototype to a user you discover that you have misunderstood what the real issue was. My favorite tool for prototypes (or mock-ups as they are sometimes called is Balsamiq. There are many other options as well – but when your goal is understanding of problem/solution it is usually much more efficient with a lo-fi prototype rather than a hi-fi. Without fail (in my experience), the discussion around a hi-fi prototype keeps getting drawn into graphical design like “wouldn’t it be nicer with this color or wouldn’t it be better if that button was in the lower left corner instead. I prefer having those discussions around the actual solution rather than having a detailed design in a different tool. There might be exceptions, for example when the nature of the development environment is such that creating a hi-fi prototype is significantly faster than drafting the real solution (I experienced this in the end of the nineties with interactive digital television).
When should we Buy a solution and how do we go about figuring out what to Buy? That is a big topic, but here are some guidelines:
- Consider Buy when the solution is not core of what you do and there are options in the market that will be cheaper and/or better than what you can achieve
- Developers often prefer Build over Buy (at least if it is something fun) so you might need to sell the Buy option to the team
- Always consider what is best for the company in the long run and remember maintenance is usually a huge part (we used to say 20 % for original development, 80 % for maintenance)
- Do a proper evaluation, see below
Evaluating Buy Options
Far to often I meet teams who choose the first option they run across. Sometimes because a seller contacted them – or because it was the only solution known to the team.
This can be a major mistake if we are talking an important component in your product. It is usually worth spending some time properly evaluating the options. The smaller the component is the faster it will go, but you should cover all the steps at some level. It is roughly done like this:
- Define and fully understand the needs
- What are the most important parts of the needs – what will determine which solution you choose
- Define constraints (for example budget or time to implement)
- Create a long list of options
- Based on needs and constraints you can usually quickly come down to a shortlist of roughly 3-4 options that are most interesting
- If the choice is important you would normally want to both get your hands on the main options and have demo calls with salespeople so you can get a better understanding and answers to your questions
- Get and review offers
- Score options versus your needs and choose the best fit
If it is a big decision it is usually worth documenting both why some options where selected to the shortlist and why the final choice was made.