Designing a most valuable product (WIP)

After more than 10 years in the tech industry, I've seen my fair share of strategies when it comes to building product at the MVP stage.

At the beginning of my career, I believed the more technical the product would be, the more it would be successful. I was an engineer proud of my technical knowledge, and let's be clear, I wanted to show off 😄.
Along the years though, I realised the faster the product was in front of the customers, the most successful it tended to be.
When I was working at mojo, Francescu and Jean (the founders) pushed this philosophy at the extreme, even when the product was already generating millions of dollars in revenue.

In this article, I wanted to develop what it means in practice to build and design a most valuable product, and how I've applied this to build all the product I ever launched, including Edith & Nous which rapidly became leader on its market.

The key steps of design for MVPs

Step 1: Decide what you wanna build

Although people usually know what they wanna build, I've seen a lot of questions around about finding ideas on what to build.

If you already know what you will be building, you can skip this step and go directly to the second one. If not, here are some tips to guide you in your decision.

Avoid crowded markets

I'll start with the obvious, but don't make another delivery or messaging/social-media app, unless you absolutely know what you're doing.

In fact, check out the apps you have on your phone. If your idea is really close to one of the mainstream apps (Facebook, Instagram, Snapchat, Twitter, Spotify, Uber/Uber Eats, Airbnb, Bookings...) you use everyday, it's likely you will fail.

There are multiple factors for this forecasted failure, but here are the main ones:

• Crowded markets means a lot of competitions, and higher budgets tend to win customers attention
• The more generic your idea is, the less likely you're to bring something new to the table
• These apps have multiple years of iterations, and any attempt to replicate those iterations at once is doomed to fail

Avoid building companion apps

For the same reason you should try to avoid crowded markets, you should also avoid building apps relying on those bigger players, unless you're absolutely sure the market isn't gonna change anytime soon.

We all know plethoras of indiehackers running Twitter analytics apps, don't we? 
‍ilo.so and blackmagic.so are two notorious examples of apps made by two famous indiehackers that tend to perform quite well. True, but how much are failing to do the same but still relying on the same Twitter API ?

By building on what everyone has also access to, you enter some sort of crowded market even in your niche, so you tend to encounter the same issues.

Furthermore, Dan Rowden (the creator of ilo) experienced the hard way how fragile companion apps can be when Ghost decided to move in the same direction he relied his business on.

‍

12% churn is in fact not a high price compared to the countless stories of business that just collapsed once they had proven their market was worth the time for the core product team of the apps they were based on. In fact, Shopify is notoriously famous for killing successful companion apps and absorbing their market share.

Don't get me wrong, there might be some times when building a companion apps lead to a very successful business, mojo is a good example of that.
The key difference is that their product does not rely solely on the base app (Instagram), and might have value for the customer outside of the original ecosystem (in fact, mojo is trying very hard to get out of the Instagram story format for this very reason).

You won't disrupt anything at first

One of the most common mistake is believing your product will disrupt the market, or worse, the whole world once it goes live. I've been there and done that.

Actually, when I was building M4dNation (my first company) back in 2015, we had this headline in a local press magazine after we said we wanted to bring players and game developers closer together and fix the game development market.

M4dNation will disrupt the video game market with Yggdrasill, its crowdsourcing platform.

We disrupted nothing, and the company was, from the business point of view, a massive failure 😄.
I did exactly the opposite of the advices I give in that guide, so no big surprises it did not become the new Valve. Still, I learned a lot so I consider this a valuable experience I can share with you today.

Let's take Elon Musk example: he is sending rockets to the moon (literally). But he didn't not started with that. How could he have? It cost billions of dollars of funding to work on space travel and a lot of knowledge.

He started with something much more modest, basic software development and slowly went up the ladder from selling software, to Zip2, to Paypal, to Space X and finally sending rockets. It took him 10 years to do so (and he is considered one of the fastest entrepreneur when it comes to building and launching innovative systems).

Think different

Now that we have seen what not to do, let's look at what we can do.

Bootstrapping is a game of focus and thinking different in order to stand out. In order to find ideas, you should look into what makes you different as a being and see if there is a niche down this road.

Popular indiehacker Pieter Levels did this when he first started nomadlist and then actively worked in expanding the niche further with remote workers/async workers.
All of his work is dedicated in solving what matters to him, digital nomadism, and he was his first customer as he actually created the product for himself before sending it live.

In order to find fresh ideas like Pieter did, here are some areas you can look into in your personal life:

• What are your hobbies? Is there any pain points you think are worth being solved?
• Are you working in something atypic and can technology help you in any way?
• Do you have a different way of life that could interest other people?

Once found, do not overthink it and try to keep in mind you just wanna solve your own problem. We tend to be pretty hyped by our ideas, which leads to making things more complicated than they should be.

If you wanna know more on how to pick ideas, Pieter explains a lot about this in his book, which I highly recommend you to read if you haven't already.

This leads us to our second step, narrowing the scope of our work.

Step 2: Narrow the scope to avoid overwork

Now that we have our idea and we believe it's worth pushing further, we need to make sure we won't overwork and make things too complicate.

Keep it simple stupid

KISS is a design principle stating that most things work best when they stay simple rather than made complicated. It's a very well known principle in software engineering, although it's often overlooked or misunderstood.

The idea behind the KISS principle is that we should not overload our product with features and complexity, when solving the problem should be clear and simple. By nature, the human being is willing to do more with less so we need to embrace this and go straight to the point.

When you think about your idea, try to only keep the most straightforward path to solve your issue, and avoid adding additional things or adding extra configuration.
As an example, my stepfather asked me to create a software for him to track the evolution of prices proposed by contractors when they deal with him regarding building public infrastructure.

‍

During the discussion, I asked what would be the expected features of such a software, with pure curiosity. His answer was:

I just need to know if the contractors are trying to make me pay more than I should for the work they propose.

The two important information in his sentence are the use of the I pronoun, and the price comparaison. The fact that only him would use the software hints me that it's probably best to try to solve the issue with a tool he uses daily rather than create something only for him, as it would reduce time and technical complexity. To compare prices over time, I suggested we tried adding the data in a spreadsheet and use basic maths to visualise them. We drafted a chart in an hour and the problem was solved.

As you can see, we didn't need to develop something new, nor try to add more work to the task. He had a problem, we kept it simple and solved it.

It also generated new questions and additional needs which, at some point in the future, might lead to the creation of a software, but for now, it's not necessary so we just used an existing one.

Applying the YAGNI principle to product design

YAGNI is a design principle

Step 3: Design your technical solution

First, a bit of semantic might not hurt. When we talk about design, we do not mean graphical design, but product design. Of course, those two notions are often tied together as most people evaluate the quality of the things by their look.

Still, it's a dangerous shortcut as a lot of product does not require to be beautiful to be successful. The most obvious example that might come to the mind is Zoom, which exploded during the pandemic mostly because a lot of people from the 70s needed to keep in touch with each other.

The particularity of this cohort is that those people were not familiar with modern UI and Zoom did felt really familiar to what they are used to use at work, despite being quite ugly for the millennials that are more used to social networking apps like Facebook or Messenger.

The key lesson behind this is that products are meant to be used by people, and their value is only perceived by said users.
If someone gives a review about your product but is not your customer, take his advice with a lot of caution as he might not have all the information in hands.

In the same spirit, designing your solution does not mean picking a technical solution to cover it up.

All you need is a pen and a piece of paper

The trap of using UML too soon

Prototyping is part of the design phase

Step 4: Build your most valuable product

Build to solve a problem

Nobody cares about your tech stack

‍

‍

‍