[Weekly Retro] Why do we productize?
#267 - Nov.2025
Hi there!
Here are some ideas to think about during the weekend.
Why do we productize a solution?
What does it mean to productize a solution?
Is productization a process?
Someone asked me this at a recent AWS event. It made me think about what actually drives teams to productize their solutions and what does the word "productization" actually means.
The answer is not trivial.
I've been in endless philosophical discussions about what makes a product a product. While everyone has a slightly different definition, most concepts converge on this: anything created to solve a specific customer need, make economic sense for a business, and made feasible through technology.
The question "why productize a solution" feels ambiguous to me. After all, a solution should already address all three dimensions: customer needs, business value, and technical feasibility.
But when most people talk about productization, I think they mean: making a solution scalable, configurable, and replicable. Productization is often seen as a way to sell something at scale, or make it "marketable".
But, shouldn't scalability be part of the original design?
Yes and no.
Thinking about scalability and flexibility from day 1 is good practice when designing a new solution, but in reality, this is rarely the case. Finding market fit and iterating on customer needs force teams to trade scalability for speed of delivery. On the other hand, let's be honest, not all solutions should become fully customizable or scalable. Sometimes the solution is sufficient to cover current demand. And that's ok.
So what signals tell you it's time to rethink your product strategy towards scalability and flexibility? I've seen three key drivers:
- Customer demand. This is the simplest and most obvious reason. Your customer base increases and your original solution simply isn't growing at the pace of the business. You start saying "no" to opportunities because your system can't handle them.
- Operational overload. While related to customer demand, this is the other side of the same coin. A team is struggling to serve their customers because the load of keeping the solution running consumes all their capacity. There is no space for product improvements and innovations. You need to reduce your cost to develop new use cases and support existing ones to make space for the rest.
- Intentional opportunity. Your product vision might already consider new opportunities: new customer cohorts, geographies, or market segments. This becomes a forcing function. You are forced to design for scalability because you are intentional about where you're heading. The risk here is over-engineering too early. Watch out!
The first two are reactive. The last one is proactive and intentional. Yet, all three are valid reasons to productize. The best teams watch for these signals and act before the constraints become too big.
What signals are you seeing in your product right now?
💡 Inspiration of the week
The work of the photographer Charles Brooks on "Extraordinary Instruments" is just breathtaking! He explored the Architecture In Music finding hidden spaces inside instruments.
👨🏻💻 Interesting links
- A very insightful investigation post inside the hidden world of companies with traceability tech targeting politicians, journalists, celebrities, and activists around the world.
- The UX butterfly effect: understanding unintended consequences in design and how to plan for them.
- Great list of use cases and prompts for product teams.
🖋️ Quote of the week
“One thing you learn: if you want to reveal yourself, you also have to know where to stop.” – Keith Jarrett
