Should I wait another week to have my first user? — Planning a product release
By: Mariano Cocirio
Tags: Product, Management, Startup, Technology, Product Management

Should I wait another week to have my first user? — Planning a product release

When deciding on when to release a new product become the blocker.

Let's put us in context, you have been researching and validating this new product. You have identified different users and now you need to plan the execution and release of the product. That's the point this story begins.

MVP vs MLP

I don't want to go into a lot of details in the differentiation between MVP and MLP, there are plenty of articles about it, the basic idea is that on an MLP you aim to get a few early users who really love your product rather than a ton of users who just like or use it.

By building your first MLP you are aiming to also get early promoters, this is something really important as to make them love your product you really need to focus yourself on some specific aspect they appreciate, and some times this is not a functional requirement.

This doesn't mean that your functional side should suffer, but maybe you should focus more on getting what thing you should do amazing instead of making a lot of things good enough.

Planning what to build, and why to build it

It's important that you define what you will be building for your MLP, but it's even more important that you know why are you building it. This is not about quantity, it's about quality and value for your user. You need to focus on building high-value features really well.

Identify your early users

Talk to all your users, and identify different commonalities across them to be able to segment your user base. Maybe your product public is too big, so it's important that you are conscious of who are you targeting in the early days.

Probably that huge client who already has a system in place that they've been using the last 15 years and you are aiming to replace is not your ideal first user, or maybe they are, it really depends on your product and your understanding of your users.

Where is the value?

Identify where the value is, and exploit it without losing the count of effort required to do it. Focus on providing a great experience and solving the high-impact issues for your user. But be mindful of the relationship between value and effort, you don't want to have a forever in-development product. No value is actually there until it's shipped and used by your user.

Photo by Marvin Meyer

Planning what to release, and when to release it

Besides the planning on execution, you also need to plan on how you'll release the new product. What strategies will you take to handle the release and follow up the early feedback so you can iterate on the current product?

Cost of delay

There is a cost we sometimes forget, the cost of delay. Not releasing some times can be lethal, all our products have a limited shelf life, and every moment we are holding them, they are losing value. Dave Masha goes through this a little bit more in detail in the following video.

The value of getting early feedback

The earliest you can release it's the earliest you can get feedback from real users and iterate over your current solution. You might have an idea of what is best for your users, and some hypotheses about them, but getting to observe them using the product by themselves is usually invaluable. Also, you can spot pain points, frustrations, and prioritize the next iteration based on your users' feedback.

It's better to know that certain interaction is not really intuitive for users during the first couple of months and after implementing just a couple of features than 1 year later with a full product shipped. It's quite an exaggerated example but it makes the trick.

Scale your release

This is not something possible with every product, but something I've found useful in my experience (mainly B2B) is to plan an incremental release including more users on each iteration when we include features that will actually provide value for them.

What I mean by it, is that sometimes you might be able to onboard certain users with less functionality provided than other users, as they might not apply for them. Let's say your product is a stock manager for stores, not all users will be interested in being able to manage multiple stores as they might have only one store, so you don't need to wait until the multiple stores' manager feature is ready to release it for this group of stores.

Also, if there exists a good relationship with the users they might be open to conceding functionalities, for example, if there are 6 parameters, and 4 of them are modified on a yearly basis then you can talk to them about adopting an initial release where those 4 parameters can't be managed by them.

Summary