Productize Or Not Productize, That Is The Question

Hi fellow product lovers, this is the first post about product management on LinkedIn where I will share some thoughts and experiences of my years working with part of the product management role without the job title and now as a full-time product manager at a tech startup.

I could’ve started with prioritization, product vision, roadmap and so forth, but there are plenty of this already and eventually, I’ll write my thoughts on that. For now, I wanted to get real and write about what really could happen in the real world, where not always the methodologies are followed and the product looks more like a service than an app or SaaS, different of products usually discussed in product management articles.

So let’s cut to the chase. What I mean by “Productize Or Not Productize, That Is The Question”?

Well, this is simple, product managers often are the ones responsible for driving the productization of an idea, process or service and by productization I mean to turn these raw elements into a scalable, well defined, scoped and marketable product. This is the dream, but sometimes we need to get the hands dirty before and build the clean, pretty and scalable product later. One of the key factors is the current company or product lifecycle stage. 

Product Lifecycle 

As shown in the chart above, as time goes by and the product is successful, sales go from near 'nada' to the skies, but not forever, because eventually customer needs and markets changes and sales tend to decline.

If your product is still in early development and it's being introduced or validated by the market, you will probably face the decision of build fast with possible high technical debt or have a focus on quality and risk losing time to market.

This is a trade-off that product managers need to deal with almost on a daily basis on startups.

 Usually in these cases, we hear people say they are building the MVP (Minimum Viable Product) that is sometimes used not to refer to minimum product, read as something as presentation, spreadsheet, software or anything that tests hypotheses as taught in the great book Lean Startup by Eric Ries, but just as a product with fewer features and lower quality.

 But what to do after we validate our early hypotheses with the MVP and the company strategy requires an initial growth?

MVP vs MSP

There are several types of MVPs that can be used on different occasions and to test different types of hypotheses, but I will use another abbreviation just to make clear the main objective, MSP - Minimum Sellable Product. The main difference is that in this case, instead of validating features and customer needs, the focus is on reaching business goals due to the company strategy.

Let's get an example:

Imagine you had $100k on the bank and your team already consumed $70k validating customer needs and now through validated learning the team believes the product is on the right track with our 30 B2B customers, but in order to continue alive, the company needs one of these two options:

A - More investment

B - More profit from sales

 Let's try to get an investment.

Oh no! Our investors won't put more money without product market fit prove. They want a product with more traction and at least 100 customers with a hint of a healthy business as good gross margin, LTV, low churn and growing recurrent revenue as shown on this entrepreneur.com article.

I know right, what jerks. But in real life is not easy to get money thrown at you with just pretty words saying that you will change the world. You will most likely need to prove yourself, your company and the product.

So option "B" may be a prerequisite for option "A", in our fictitious business case.

In this case, we need to use our remaining $30k to reach more customers, make surviving money and validate product-market-fit. 

That's when we could use a minimum sellable product that essentially is the product-ish with the minimum feature and quality accepted by customers so we can reach our goal.

For a product team, this is not easy, it means technical debt, products that won't have an incredible customer experience to impress the customers and will probably have everyone working more fixing bugs and giving customer support than running nice sprints to develop nice productized features.

So now using the analogy of the image below, we try to make money selling low-quality bikes for people who want cars.

Photo: Content Marketing Institute

That's life, sometimes it gets worse before it gets better and it could be the difference of a company dead with a pretty product and the company alive with time to build a scalable.

To make sure we on the right track, is important to establish clear goals and stage triggers so everyone is on the same page about why the effort is being done and when the gears will change.

At this moment, is important that we as product leaders keep the team developing motivated and the stakeholders aware of the technical debt being created in order to achieve our goal.

So now in the business case, let's say that after 3 months of hard work the company managed to sell the product to more than 100 customers and with the new revenue, there is still $30k in the bank.

Now, not only option "A" will probably be easier, as the team most certainly will have learned a thing or two about the product-market-fit and will be ready to keep going on the product strategy of developing something scalable.

Yeah right, this is that simple.

That's a pleasant meeting, the product manager saying to sales executives that we will slow down sales to focus on improving the product so it can be more scalable.

Why to stop now? Why not go for 500 customers, just hire more developers and support analysts and let's make money?

That's when the product leaders need to be persuasive and data-driven to show why this will be probably a bad decision.

Showing the growth curve, studies, customer research and case scenarios of what it's likely to happen might be needed.

Just wait for customers to start to churn and operational costs of fixing bugs bite off all the revenue can be risky and way worse than the previous moment when we had just a few customers but with fewer costs and risk of brand damage.

Conclusion

So while as product managers we look for productized solutions, sometimes we need to manage products that aren't as good as we would want so we can meet business goals and validate hypotheses. Is important to have resilience and help the team to go through this phase learning the most they can so everyone is ready for the next iteration of the product that should aim help the customer solve their problems in a scalable way. 

Please let me know if you have already faced a situation like that and please follow me here on LinkedIn and visit my Medium profile where I will keep posting articles about product management.