I was inspired to write this post by the following pictures that I’d included in my lecture material a few years. Writing it in a bit of a hurry since the class starts soon! (but it’ll good enough to make the point)
(You can find the original source for the pictures by googling.)
Okay, a couple of things.
First, it’s highly important for a startup to define both the problem space and the solution space relating to their product. This includes the particular pain points that the customer whose problems we’re solving is experiencing – at minimum, solving one pain point, if substantial enough, suffices to make a successful business. The solution space includes the competition — here, it is super important to consider not only the direct competition (a common mistake) but also the indirect competition.
I call it the “pen and paper” test — can the problem you’re solving, most often with a high degree of technological sophistication, solved with a simpler, non-technological way?
And more importantly, how are the customers solving it now? It takes a lot for them to change their habits, much more than what founders typically think. The customer will not download an app to solve the problem — no matter if it’s free or not — unless the app provides a solution several magnitudes better than what he currently has. So, bear this in mind.
Second, once the gravity of the problem we’ve set to solve has been “validated” by more trustworthy means than guessing (such as customer development), the problem dimensions need to be tied formally into the product features the team is building (the second picture depicts this).
This way, we avoid waste in the startup development process (remember, waste is your biggest enemy because you’re always on borrowed time).
Third, after this the usage of these features needs to be backed up real usage data — in other words, the product needs to be exposed to real users whose behavior is analyzed based on engagement metrics (e.g., time they spend with the product, what features they use, how frequently, etc.). For this, there needs to be a good analytical system built into the product. Follow the Facebook guideline here: you don’t know what data you might later need, so store everything. This enables maximum flexibility for subsequent analyses.
And finally, of course when we get feedback on the usage of the product, we tie it back to the problem we’ve set out to solve and conclude whether or not we’re actually solving it. If the data suggest low engagement, we need to start over and make radical changes to the core of the product. If the data gives us a nice depiction, we’ll still continue with further adjustments to improve the user experience (which, of course, is by definition never good enough).
That’s it. Thank you for reading (and I’m off to class!)
Dr. Joni Salminen holds a PhD in marketing from the Turku School of Economics. His research interests relate to startups, platforms, and digital marketing.
Contact email: [email protected]