Speed and haste are not the same
“We want something as soon as possible, because the market is not waiting.” This is often the argument for wanting to start building software quickly. And it's not just the market that's putting pressure on companies with a new, innovative product. Often, promises have already been made to stakeholders or investors, or the budget is limited. But aside from the tension between speed and quality that comes with every creative profession, there is another important reason not to write code right away.
Take time to think
Because taking the time to think carefully now will save you enormous time. Or, to put it negatively: if you start hastily now, development will probably take time longer. Or, in the worst case, your product won't reach the finish line at all.
After all, the financial risk of an MVP is already quite high. We still often see that the interpretation of “agile” comes down to “we'll put something live and we'll see”. And you may achieve a good result that way, but it is almost never the fastest and certainly not the cheapest way.
So from day one of a product development process, we always compete to take enough time to think, even though we know we need to deliver quickly.
Because we don't just want to make a product, we want to make a product that people actually want. And that is exactly where the challenge lies. Because hasty decisions — that is, decisions made without the right knowledge of the market — can be expensive later.
A different way of looking at product development
At Blis, we also know from experience that a thoughtful approach ultimately leads to a beautiful and commercially successful result more quickly. That's why we've developed an approach that combines the best of both worlds: eliminating risks and accelerating development.
We mainly get that speed from our experience, extensive toolset and efficient way of working. We mainly eliminate risks with our entrepreneurial approach. Because at Blis, we have the ambition not only to bring development projects to a successful conclusion, but also to work with the people who invent and market the products. Sometimes that goes so far that we become shareholders, but this participation usually takes the form of taking a critical look at the product and market and the associated choices. That includes supervising and advising product owners for example, also with.
The importance of the right focus
Very often, we see that companies are often already in the right “problem space”: they have found a valuable problem area where challenges must be solved and where there is therefore money to be made. In short, they know their market well enough to have an overall picture of what their potential customers are struggling with. But that is not enough, because a successful digital product does not solve general, but very specific, concrete problems. And those specific problems, which many companies still don't have to deal with when they come to us. For a successful product, we therefore still need to refine the problem statement.
The conviction that you can do this with pilot projects often leads to problems, because you often still do not have a clear enough picture of specific, crucial and concrete problems when building those pilot (s). While you do spend a lot of money on construction. This is where our approach stands out. Instead of immediately starting to build, we first take the time to clarify the problem. Because we know from experience that this investment in the preparation phase pays off twice.
Our step-by-step plan to a successful product
So we do more than just develop a piece of software - we become a real partner in the process of product development and so we also contribute ideas about finding product-market fit and spending the investment budget wisely.
Here is the step-by-step plan that we follow:
- Concept and visualization - the concept car
For a clear product vision, you first need a clear picture of what you are creating. So we start with a good concept plate or visualization, as the car industry often brings market and innovation together with showing a concept car. Images and models simply speak to more than just words. This is how we already excite stakeholders, potential investors and end users and force ourselves to make our ideas concrete. This approach helps us to better understand why the idea is valuable to the various stakeholders and the business. The visual concept that we develop in this phase, although it still “does nothing” technically, is sufficient to collect this very valuable information. By using these types of techniques, once we start building, we can strive for a 'one-time-right' and thus spend the budget in a much more focused way.
- Working prototype
A first prototype answers the crucial question: do we have the problem in focus? It can be a mini app, but also a clickable Figma prototype. In no way does this look like production-ready software (it's more like a soft drink machine with a software developer sitting in to manually count the money and throw out a drink at the right time), but it can already show users how the software will work. So, as developers, we can use it to gather valuable knowledge about our users.
- Proof of Technology
Now it's about proving that we can get the technology to work. We'll omit all the beautifully designed screens for a while and make a technical prototype. When we type in a command, we see the system respond, make the appropriate API calls, and come back with data. It's the digital version of the 'breadboard', a board where electronics specialists test new circuits (and what to the untrained eye looks like a board with a wild bunch of wires sticking out): no one but a developer understands it, but it gives the team confidence that what we want to build is actually possible.
- MVP (Minimum Viable Product)
If all previous steps are successful, technology and concept come together in the MVP. We are now building this with the confidence that the major risks have already been eliminated, so we can quickly roll it out to a market that we are more or less sure is waiting for it.
The Role of Criticism and Validation
The crux of the matter is: make sure you collect criticism of your product as quickly as possible in the real world, from real users - what we call: get out of the building. At Blis, we think this is crucial, because in practice, we still sometimes build things that should have been different. Or that, in retrospect, we would have been better off omitting.
Time and again, it appears that companies underestimate the costs of development. Mission critical software is always complex and always labour-intensive to make. And therefore not cheap. Development is and remains work for scarce specialists who can only spend once every hour. That's why you should think carefully about everything you build before you build it. The good news is that you can test an awful lot before you make an MVP.
The courage not to know everything
Back to the entrepreneur who comes to us and “wants something as soon as possible”. At first, they may not be waiting for our critical questions, but they usually quickly realize that we are asking things that they simply don't know yet. And that, therefore, to remove the risks from the project, more research is needed.
And that's the best way to spend your innovation budget and development time wisely: admitting that you just don't know certain things. That doesn't mean we should throw your idea in the trash at all. Your idea may still be brilliant, but maybe in a slightly different way than you first thought.
And don't forget to also save some budget for when your MVP is live. Because after the MVP, the real learning begins. A first version is simply never an optimal version, and it is precisely when your product is really used by real users that you will discover things you couldn't know before. And only then will you really add value.
Check out our white paper
Want to read more about Product Development? Then read our white paper: Why you don't want to become a product owner (and 4 things to do if you're already a PO and want to deliver successful innovations). Here are our 4 golden tips for delivering successful projects as a product owner and working on your own status in the organization.
.jpg)
