The majority of startup founders usually have both the theoretical knowledge, gained through study, and the practical experience to solve problems. But, is their way of solving problems enough to help overcome challenges when building their own product startup? Or finding the right problem to solve, for that matter?
The challenge, of course, lies in trying to solve problems using a kind of practical method, within a context that lies beyond their area of expertise. And that’s exactly what I’m going to analyze below.
Solving problems with a project-oriented mindset
First, let’s take a closer look at how we solve problems when we rely on this other mindset.
A pattern
This approach follows a pattern; there’s an initial description (comes with some restrictions) that serves as the specifications of the solution. This model fits perfectly with that of the ‘project’; whether it is a software project or any other type of project. And, in that model, the process usually takes place in two phases.
First there’s the problem exploration phase, from which functional and technical requirements arise; followed by design, implementation, control and documentation, possibly user training and a political function. And, finally, comes the longed-for deliverable. Last but not least, under normal circumstances, and at a reasonable time frame from the project delivery, comes the payment.
It comes in two phases
What’s worth-emphasizing here is that, as mentioned, such projects usually come in two phases. And, as a matter of fact, what happens in a best-case scenario is the following; first there’s the exploration/analysis and the detailed documentation of the functional and technical specifications; followed by the second stage of design and implementation. In fact, most of the time, the deliverable that comes as an output of the first phase is part of the specifications section in the project contract of the second phase.
The methodology described above has been used in technical projects for hundreds of years. And, whenever there’s was an issue, most the time, the problem had to do with specifications; writing down all the operational requirements of a project in a clear way, proved to be a quite challenging endeavor.
It may sound like an easy venture, but it’s not. And the thing is that in the worst-case scenario, even when it was feasible to write them down, project specifications were prone to change in the course of time. And that’s because people’s needs and desires change over time. As a result, though the project may have been implemented according to specifications, users were still not satisfied with the outcome.
Change in requests
If you have even the slightest experience on project management of any type, you certainly understand the issue described above. “Change in requests” is commonplace in projects of that type. And these requests may have to do with important or less important issues. But, in both cases, these changes usually lead to endless discussions and negotiations regarding planning and budget. To better understand the struggle such endeavor entails, one needs to get involved in a similar context. There’s a Greek a saying that helps better understand the struggle described above “whoever has not built a house, has not learnt life” drawing a parallel between building a house and the struggles that endeavor entails.
Problem-solving in startups
In a similar fashion, when we build a startup that delivers a product to final users, it’s as if we start a new project with fuzzy parameters. And that’s because we’re actually not aware of the functional parameters, or the technical ones, beforehand. Furthermore, we neither have a predefined budget nor a plan. We’re not even aware who our customer is or will be.
Methodologies that help us find the right problem to solve
An in-depth understanding of the facts described above, allows us to understand why learnings that derive from Lean Startup, Customer Development, Agile Development and Design Thinking are so crucial. It’s the challenges involved in these previous sections that help us appreciate the value of such methodologies; which consequently start becoming clearer. In particular, we don’t know exactly what to do at each time, neither for whom we’re developing our solution. And that’s why rapid prototyping becomes a one-way affair.
A prototype — or an MVP — allows us to get in touch with our potential customers, right from the beginning. This approach helps shape an in-depth understanding of the problems and the challenges our customers face. Note here that the majority of customers usually have a difficulty in describing what it is they actually need. That’s why we need to be flexible and push forward through fast development cycles, past our initial prototype. A process that will allow us to learn more about the market and the customers we target. Once we gain certainty at a satisfactory degree, based exclusively on experimental data — not our intuition — we can delve into our product development and get from MVP (Minimum Viable Product) to product-market fit.
Why honing your business model is actually the right problem to solve
Note here that there’s a short of pitfall in what I’ve described above. I’ve repeatedly mentioned the word ‘product’; and, in the startup world, by product we mean the whole business model. Not just the product itself; at least, not in its strict sense, as we may know it. It goes without saying, founders must develop a product for customers by gradually (in stages) discovering and reshaping its ‘specifications’. In fact, specifications will be slowly revealed; often in a conflicting way, forcing founders to take two steps forwards and one backwards. Regardless of this difficulty, founders must develop the proverbial “engine” through which customers will become familiar with the product itself; and will also get access to the respective support (content or company representatives) when needed. And that “engine” should be implemented in a financially viable — or financially sensible — manner.
Therefore, the “engine” (that makes up the business model of the company) must be built to offer value to the market and, through this offer, create value for the organization (company) that offers it.
When the right problem-orientation and the available heuristic methods act as a catalyst
What’s worth mentioning here is that it is, indeed, difficult to reach that outcome. There’s no one-to-one mapping between problems and solutions. All we have is the heuristic methods mentioned above. Despite the challenging nature of these ventures and, no matter how difficult it is to reach the final outcome, having such efficient heuristic methods in our arsenal is what makes it possible to reach our goal. Of course, we’re talking about Lean Startup, Customer Development, Agile Development and Design Thinking. To put it another way, difficulty is no real excuse when such methodologies are available for us to use.
On the other hand, what is indeed difficult, is for founders to accept the problem they need to solve. And, as long as it is their own responsibility to make the product work, they are equally responsible to make sure their whole venture does solve problems for a significant number of customers. And these customers must be willing to buy that specific solution, too. To achieve this, founders need to get out of their comfort zone; and avoid the trap of common sense altogether.
Does “the right problem to solve” even exist?
Finding the right problem to solve is difficult, but not impossible. So is finding the right market to target. But, a proof of it being absolutely feasible is the unimaginable growth of digital economy around the world; built up by successful endeavors, such as the ones where startup founders are involved.
