Improvise, Processize, Productize
Balancing productization with other work models for business success
Hello! I'm Patrick, your guide to tech, craft, and personal growth. New here? Join our supportive creative community to fuel your journey!
I was on a call with a key customer when they mentioned a problem we hadn't anticipated. My first instinct was to build a new software feature to address their needs.
After the call, I discussed the idea with my co-founder and realized a software solution would be too time-consuming and resource-intensive.
We needed to help our customer now.
Instead of defaulting to code, we improvised a manual process to solve the customer's problem, then documented it so we could repeat it in the future.
This experience highlighted my tendency toward product tunnel vision – the inclination to fixate on code-based, "productized" solutions while overlooking intermediate strategies that could create more immediate value for customers and the business.
Over a decade in tech, I built strong productization instincts, but as a startup co-founder, I've had to learn to balance them. I've found that tempering productization with two other work models is critical to our success:
Improvise
Processize
Productize
When applied together, these three models complement each other and amplify our impact.
Improvise
Early in my career, I studied improv comedy in Chicago. I spent many nights at the theater practicing my skills and watching the pros.
The pros always felt deliberate, working together quickly in an unstructured environment and getting crowd-pleasing results night after night.
Similarly, seasoned product teams can improvise to great effect.
The challenge with improvisation is that it's hard to scale with quality. You want to capture the best outcomes in a repeatable process for others to replicate. That's where processizing kicks in.
Processize
Processizing enables a steady crossfade to productization, delivering immediate value while creating foundations to scale.
In “The Minimalist Entrepreneur”, Sahil Lavingia introduces his concept of The Manual Valuable Process. Sahil focuses on refining a manual process that gets results for customers before productizing it in code.
As a software creator, this approach can feel counterintuitive because it’s based on a manual process, not software. However, it’s a high-leverage intermediate step.
For example, at Signal Sciences we built a next-gen firewall capable of handling complex security techniques. We needed to support niche scenarios faced by enterprises without bogging down our software. Instead of building features in code right away, we created processes to help our professional services team manually support the unique needs of these customers. This allowed us to sign deals with businesses we would have missed otherwise while protecting the simplicity of our core product.
These manual processes helped customers, preserved the product’s strengths, and added immediate value to the business. If we had only focused on productizing via software features our results wouldn’t have been nearly as strong.
Productize
Once you've gathered insights from improvisation and refined your process, productization can be highly targeted.
Continuing with the Signal Sciences example, our clarified process allowed us to pinpoint specific moments in the customer journey that could benefit the most from a software solution. Our bespoke professional services also allowed us to identify patterns in new requests before changing the product, making more informed choices about formalizing functionality in code.
By the time we considered productization, we had already solved key customer problems and could focus on scaling a validated process with code. We could improve our service consistency, lower costs, and intentionally transition from an employee-supported model to a software-driven one.
Final Thoughts
While productization is often the goal, I've learned to ditch my product tunnel vision – great software starts with a bit of improvisation and valuable process.
By balancing these approaches, we can maximize software's value while de-risking our investments, building on a foundation of customer understanding and validated demand.
Until next time,
Patrick
🙏 Thanks to Adam Singer, David Hoang, John Cutler, Paul Millerd, Peter Yang, and Chase Adams for reading earlier versions of this draft and providing feedback.
If you got a little value from this post, consider subscribing or sharing. Follow me on LinkedIn for more.