The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

“The fewer features you build in your MVP, the faster you may be able to get it out there.”

MVP stands for Minimum Viable Product – that almost everyone (and their dog) knows. But how minimum and viable should a product like this really be?

Today’s guest, Kurre Ståhlberg, has spent much of his life working for startups. Having worked on multiple MVPs, he discovered what works and what doesn’t through trial and error.

According to Kurre, if you want your MVP business idea to turn into a successful and sustainable product, you must succeed in three areas:

• value – figure out the unique value of your MVP,
• speed – deliver as fast as you can WITHOUT compromising the product’s quality,
• strategy – have a vision for what the product may be one day but don’t rush to get there.

Read on to learn exactly how to maximize value, speed, and strategy in MVP development.

Say hello to Kurre

Arkadiusz Kowalski: The new year has started recently, but you’ve also celebrated something different around the same time – your first anniversary as a CTO of Gubbe. What does it feel like to work in the elderly care industry?

Kurre: It’s unlike any other place I worked at.

To begin with, the company composition is very different. I was used to working in engineering companies where most people were men roughly my age, very similar to me in many aspects. But at Gubbe, until recently, I was the only man in the company of 14 or so.

The business is also different. In my previous job, we moved data from one place to another. It’s hard to compare it to providing elderly care.

What’s more, there are many regulations in the healthcare industry you need to be aware of.

Minimum Viable Product – minimum or viable?

Gubbe has been around since 2018, but I know that you’ve already experienced working with many startups. And those happen to go hand in hand with building Minimum Viable Products.

Let’s start with a classic: Do you think that an MVP can be too “minimum” and not viable enough?

Yes, I do.

Many people seem to think that an MVP is simply the quickest thing they can throw together without paying much attention to the product’s viability.

But if you do an MVP that is too basic too quickly, you don’t pay attention to the important details. It’s not really a product – it’s just a prototype. There’s a big difference between a viable product, even a minimal viable one, and a prototype.

I’m glad you said it. It also occurred to me that people who want to build new products often misunderstand the difference between a prototype, an MVP, and a proof of concept. What’s your take on this?

The way I see it, the proof of concept lies somewhere between a prototype and an MVP.

The prototype is the simplest of all. It’s what you test for yourself to see if a given concept is doable in practice. With a proof of concept, you try to prove the idea’s worth to somebody else. It usually only contains the core, the very essence of what you want to build.

Finally, the MVP is something that you should be able to sell to an actual customer. It has to have all the necessary scaffolding that one would expect from an actual product.

MVP – the ideation phase

In his famous book Inspired, Marty Cagan says that an idea must be valuable,
usable to the customer, technologically feasible, and strategically sound in the long term. 

As a CTO, you are in an interesting position to talk about it. Traditionally, CTOs focused mostly on supporting the product technologically, but we’re going to cover all four areas.

So, what makes a product idea valuable to potential customers?

They say that to get somebody to switch from one product to another, the new product must be ten times better or ten times cheaper. This may be a bit of an exaggeration, but the new product definitely must be better than the products customers already have access to in some ways.

The new product needs to bring enough value for the customer to be willing to invest the effort and resources necessary to make the switch.

Perhaps tech people could be the ones to figure this out. How can engineers be involved in product ideation? Do you agree that they should be in the first place?

That’s a difficult question to answer. I agree with that in most cases, or at least in many cases, but let’s get deeper into it.

Developers understand best what’s technically feasible. If they’re not involved in the product design or ideation phase from the start, it’s possible to go fairly far in the wrong direction only to find out that this path is not really viable. 

On the other hand, most developers, at least pretty much every one of them I know, are very much engineers at heart. Engineers have certain ways of doing things and opinions about how things should be done. These opinions may not always resonate with customers.

There are many anecdotal stories about how somebody spent a lot of time and effort building something that nobody actually wanted. The product was technically marvelous but didn’t actually do anything that people would want to pay for.

So, in general, I think that developers should be involved from the get-go, but they shouldn’t necessarily be in the center of the ideation phase, especially when you have dedicated product managers. Those people should probably be the ones who actually drive the ideation phase.

Let’s say we want to involve developers in the ideation phase according to the conditions you set. How do we ensure that the participation is ongoing? Is it more about the right processes or the right mindset?

I think that processes and mindset go hand in hand.

My view of processes is probably different from that of many other CTOs. That’s because I’ve only worked in small companies with fairly lightweight processes.

To me, processes are the manifestation of a mindset. If somebody writes down a process, then it means that this is simply what they think is the best way to do a certain thing. If a company decides to follow that process, it essentially follows that person’s mindset.

One good thing about designing processes is that you won’t miss anything obvious. For example, during a meeting in which engineers are involved, you should always remember to ask them directly if a given idea or direction makes sense to them or not.

Speaking of cooperation of development with other departments, we discussed cross-functional collaboration extensively in our series.

How can developers cooperate with the product team to achieve the best results in this initial MVP development phase?

It goes back to what you’re building.

In any project, there will always be people who are unhappy about how it went. There will also be people who are happy about the outcome, but they’re usually less vocal about it. At the end of the day, people want to do different things. That’s a big challenge in cross-functional collaboration.

I recommend having a small team do the pre-work for an idea. When the time comes to finalize a plan, they can bring in the rest of the team. Then, everybody can discuss the existing plan.

I don’t think it’s ever helpful to have a large crowd discuss a strategy from an open-ended position. It’s much more productive if you already have some kind of proposal to agree or disagree with. That creates a conversation that is focused and centered around debating specific directions to go in.

I observed the same. Whenever I throw an open-ended question like this in a group message, it takes a lot of time for someone to respond.

I believe that there are two possible courses of action if you start with an open-ended question – either nobody has an opinion, or everybody has a different opinion. You could call it an argument or a conversation in which everybody’s going in a different direction.

MVP – getting the features right

Let’s get a bit more technical. One CTO told us that they used to have a backlog full of questionable feature ideas that the client apparently needed, like a blue button. But when he dug deeper, he discovered a bigger challenge: a need to streamline distribution benefits. The blue button wasn’t the issue.

How do you avoid creating features that address a problem only superficially like that?

When a feature interests you on a personal level, when it solves a problem you consider very important, you may be inclined to build it no matter what.  

But when it comes to MVPs, the key is to understand which feature is most essential. When possible, this one feature should be clearly defined, and everything else should be built around it. This is the feature that the customer wants to pay for.

When you’re starting to work on an MVP, you’re creating something new by definition. It doesn’t make sense to build something that everybody else has. This one unique core feature that brings value is what makes you stand out. As for everything else – if you can leave it out of the MVP, then you should leave it out.

Maybe it will sound a bit cliche, but when I was thinking about how I would answer this question, the first thing that came to my mind was using the five whys technique. One could use it to determine the actual need behind the blue button, right?

I was going to mention the five whys, but then I thought about something else.

There are two fundamentally different reasons for someone to build an MVP.

One of them often occurs when a consulting firm gets an outside client who wants to build something. This client may not know what they want to build yet. They have a general idea, but they need to dig deeper to figure out the core essence of the idea. That’s where I think the five whys are especially useful.

But then, you may also have a product company that tries to figure out the core essence by itself. If you are not going to consult your idea with an outside party, asking the five whys may feel a bit like running in a circle because you lack an outside perspective. At the end of the day, you just need to find a way to determine the core essence of your product one way or another.

You’re talking about the one core feature, but let’s discuss the opposite end of it – how to avoid building too many features from the start?

Once you have the core, you need to exercise some self-restraint and avoid building anything that you don’t need.

You need to create a viable product with some necessary scaffolding because you need to take care of things such as user management.

For everything extra you build, ask yourself if you really need it. As I said, doing this is especially difficult when the extra feature is fun.

One of the most important aspects of an MVP is delivery speed. You can improve it by using better tooling, but another method is to simply build less. The fewer features you build in your MVP, the faster you may be able to get it out there. When it’s out, you may start getting feedback for it, which is also essential.

MVP – the right technology

There is another angle to the issue of delivery speed in MVPs – the technological one.

Some say that you can put together MVP quickly because it will likely change a lot and may need a total rewrite anyway. But perhaps it should sometimes be built to scale from the start?

Many people think they can quickly put an MVP together, then throw it away and rebuild it. But in my experience, this plan always fails. In fact, I have never heard of a successful rewrite like this.

However, I did hear about rewriting products piece by piece, but these schemes usually take place a couple of years into the product’s life. That’s why I wouldn’t really bet on rewriting an MVP. You need to build a viable product from the start.

On the other hand, you need to balance your development with speed. Somebody once said: “if you build it right, you’re building for when your customers have already moved on.”

The vast majority of big, successful software products have horrible code in their core – it’s the original hastily written code. The product may have changed direction multiple times, but the code remained.

If you build your MVP like any other kind of software, by the book, to the highest engineering standards, making sure that it scales from the get-go, you most likely spend too much time building. By the time you are done, nobody may care anymore. And then, there’s a chance that you’re building something wrong altogether.

It seems that when it comes to MVPs, perfection is the enemy of good. 

But perhaps you can get more value for your time by using AI tools. Some believe that you can almost prompt the entire MVP without engineering knowledge. What’s your take on this?

If we were to divide an MVP into two parts – the core feature and the scaffolding –  then I guess you could say that the core needs to be built more or less by hand, but everything else could be built with AI.

For example, if you’re building a SaaS web app, you could put together the UI using AI. I’ve actually done it myself multiple times over.

But if you don’t know what the true essence of your MVP is, AI is not going to figure it out for you. Even if you do have something in mind, it may be difficult to prompt it into AI if it really has some kind of novelty to it.

To sum it up, AI could write 90% of the code, but there’s a novel part that should be done by hand.

AI tools definitely are a massive time saver for MVPs. If you have an experienced developer or two, they could use them to help put together an MVP quickly.

In most of such scenarios, you’re also going to have to work with the product team. How do you align the initial technological choices with business objectives?

In the beginning, it’s actually really easy to align these two because you have nothing but business objectives, right?

But once your business objectives shift and you need to modify what you set out to do, things get much trickier. How can you protect yourself from that?

I don’t always follow the advice, but I believe that choosing boring technology is the way to go. I’m talking about the kind of popular tools that everybody uses. That way, your software will be more likely to fit changing business objectives.

MVP – strategy

Finally, let’s talk about vision. MVP may exist to validate a project idea, but its creators still have a vision for what it can be someday.

Do you think that an overly ambitious vision may lead to bad strategic decisions at the beginning, such as focusing on too large of a target audience or, again, building unnecessary features?

I think the opposite is true – an ambitious vision is necessary to succeed. But it’s important to distinguish between the vision and the scope of the MVP.

For example, as I understand, OpenAI started with a vision to build AGI from the get-go. But they had no idea how they were going to do that.

At that point, they decided to build something smaller and more manageable, like a chat. They didn’t know if it would lead them to the creation of AGI. Still, they decided to make the first small step and test it out. Based on the results, they took another step. They believed that all these little steps would eventually lead to AGI. That was the grandiose vision.

If you are a product company, you need a vision – it is your North Star, your guiding light. However, you also need to be able and ready to scale it down to what you actually can do right here and now. There’s this old joke: How can you eat a bear? – piece by piece.

Perhaps some data can help you take these small steps towards your goals. In addition to surveys and interviews, you can use quantitative data about end-user behavior or perhaps even business intelligence platforms.

As someone strongly interested in machine learning, how much do you prioritize using data to make long-term decisions about MVP development? 

I like having data to guide me, but MVPs are quite tough to use quantitative data for. 

At the MVP stage, you typically don’t have many customers, especially as a B2B company. As a result, you are not likely to have statistically significant numbers. 

I’ve seen so many times when someone tried to make a decision based on too small of a sample size. Such data may be completely off just because of a random chance.

So, in many cases, you just need to rely on qualitative data, talking to your customers, and your gut. 

General advice

Let’s sum things up. Given all we’ve talked about, if you were to give one piece of advice to a CTO who is going to begin a new MVP project and wants to connect with its target audience, what would it be?

To get credible data to inform your MVP development, you need to engage your customers directly.

Talk to your product’s actual target users. They will give you the information you seek. Don’t rely on secondhand information – it all comes filtered through somebody’s opinions and agenda.

Resources

Could you also share some recommendations of resources, such as books or podcasts, for those interested in the subject?

I’d recommend a classic – Lean Startup by Eric Ries.

I first read that book around 8 years ago. It must have been the first tech business book I actually enjoyed.

I love reading, especially fiction, but I’ve always struggled with certain types of business books because they tend to be boring. Lean Startup is one of the exceptions. It describes many of the concepts I’ve been talking about today in a really engaging way.

What’s next? 3 MVP rules for CTOs to follow

So, what do you think? Are you ready to create a minimal viable product that is likely to receive excellent user feedback from your target audience?

Like the early adopters of lean startup methodology, you are reminded again that MVPs really do require a lot of thought and hard work to produce a proposition that can be reliably tested in the market.

Don’t let poor execution ruin your business idea. Think carefully about your minimum feature set. Follow Kurre’s advice and:

• Determine the single most important feature – this feature should be decisive in getting strong customer feedback.
• Build a quality product from the start – prioritize high-impact tasks and use AI tools to save time.
• Have a vision, but don’t act as if you know how to get there – make little steps based on how well your MVP performs. 

And most importantly – get the data you need to do that straight from your customers.