This is part three of a series about my hands-on experiences with over a dozen startup strategy projects over the last 5-10 years and patterns I’ve learned by watching hundreds of others coming and passing.
- In part one, I’ve stated that I truly feel we are forcing the market to follow the tempo of the startup and that is in my opinion one of the biggest reasons for startup failure.
- In part two, I’ve demonstrated how you can practically find your current place in history and what the consequences are for your strategic gameplay if you decide to respect that timing.
- In this part three, I want to show you how to leverage the entire ecosystem around you to influence the progress of the market while organizing yourself in a ‘lean’ fashion.
What’s your problem?
The most important and difficult part of a startup Product Market Fit analysis is truly being able to describe the problem they are solving. Many, many organizations do not understand this well enough. But it is vital to what we will be doing next. There are two aspects to getting the problem description well defined.
Jobs to be done
The first is the “Jobs to be done” principle. The idea here is that the actions a product does, are rarely in itself the reason you are buying them.
Allow me to demonstrate: in broad strokes, there are two types of electrical bicycles. On the one hand, you have the regular e-bike your mom and dad bought to be able to cycle many years longer than they otherwise would have been able to with their weakening knees. And on the other hand, you got these 45 km/h speed-pedelecs your hipster neighbors bought to commute to work 30km away. Their needs were “healthy, and environmentally friendly, personal transportation to work“.
Both NEEDS can be solved with different alternatives (competition). For your mom, there is the hometrainer, but then they won’t be enjoying the outdoors as much. And your neighbor could have bought an e-scooter but they also wanted to be more healthy.
If you’ve never heard Clay Christensen’s story about the McDonalds milkshakes, you truly have to watch this (7min) video where he brilliantly describes the problem & alternative solutions concepts. And if you like this video, go ahead and read his book Competing Against Luck.
The pain chain
The second important aspect I want you to understand when it comes to needs is that everyone is solving someone else’s problems. If you understand this well, you can find buyers of your product that aren’t necessarily your users, but have more influence and decision power. This concept is called the ‘pain chain’.
In my example of the bicycles, one could argue that employees who come to work on an e-bike are healthier and happier. So we might be able to sell them directly to an employer who’s need is lowering their turnover rates or sick days. And it’s much cheaper than company cars! Double Wham.
Value Chain
While I showed you in the first two blogposts what the concepts of evolution/maturity are in Wardley Mapping, that’s not where we are going to start when doing a Mapping exercise. First, we start with the user need as described above, and then we are going to map the entire value chain. It’s a top-down stacked list of dependencies to solve the user need.
When you add up the user need > the value chain > and the maturity of all of its components, you have generated your first Wardley Map.
Evolution
Once you have your Wardley Map, you can identify all the areas that need improvement in order for your user’s needs to be solved cheaper and more efficiently in the future. And this will then follow the patterns of climatic change we described last week through competition and collaboration.
The whole reason I’m showing you all of this is that once you have built your entire Wardley Map, you’ll soon realise that you clearly do not have all the resources and time to solve all of the challenges in house. You only have a very limited number of problems you can tackle at the same time. This amount is limited by your monetary resources as well as your team’s ability to focus on a specific task. Why do you think Elon Musk builds separate companies that ultimately are all suppliers to Tesla? He has the money but wants everyone to be focused on just one part of the problem. It is also the exact same reason Tesla started by just building the electrical engine and didn’t put any focus at all in the ‘car’ part of their first gotomarket model, the Roadster.
Practical Example
This all sounds very nice in theory, Hans. But why don’t you show us how you implement this in practise? The following image is from an analysis I did 4 years ago where the need was warning visitors and co-workers in the dangerous parts of a worksite that they were not wearing the appropriate PPE (Personal Protective Equipment). We had to use CCTV cameras and could not rely on the internet for safety reasons.
if you are not technical, please ignore the mumbo jumbo and just focus on the visual
At the time we had some custom-built prototype architectures. When we looked at the Infrastructure Centric components of the solution stack, we noticed at least three areas of improvement that were limiting the cost efficiency and our rate of progress;
- Localization: in order to truly decide whether or not a person was in a dangerous zone we had to localize an object in 3 dimensions on a 2D camera image. There were (are?) no open solutions for that we could source. The only thing we did at that point was manually drawing areas.
- Inference Engine: we had scraped together the bare minimum to create an inference engine that classified and analised the images.
- Edge Devices: we were custom integrating cases with NVIDIA boards and every installation would have had different components depending on what was available at the time.
Strategy gameplay:
- This easily helped us decide that we would let the market evolve the edge devices, it would do that anyway even without our help and we would benefit from its evolution. We just had to make sure our integration was designed for change.
- For the Inference Engine, it made no sense to productise that part of the solutions stack internally as it was way too far from the need of the users (our interest), so we started partnering up with experts in inference engines.
- Lastly, we could still get away with the manual localization during the implementation phase so we only had to make that easier. We would in parallel invest some research time to investigate if we wanted to add some effort in creating an open source project to create the IP publicly until we could let it go.
Bottomline
Sometimes it can be truly necessary to build low-level infrastructure components to even make your products work as a prototype, an MVP or even the first generation(s) of your product. This is however expensive to do and even more expensive to maintain in the long run. But after doing this analysis, we could with great confidence say that we needed no additional resources, and that our entire team could remain focused on the values closer to our users.
Doing this type of situational awareness exercise every 6 months is how you stay on top of your game with the LEANest possible organization, ultimately waisting as little investments as possible towards your end goals.
If you are interested in any of the insights I can bring to your company, I do recommend you have a look at my service page and schedule a meeting. https://hansdeleenheer.com/services/