Build vs. Optimize: A false dichotomy in product management, and when to rely more on one strategy over the other
Don't believe the clickbait; any product manager worth their salt builds AND optimizes.
Don’t be constrained by the false dichotomy of “Builder” vs. “Optimizer”
You may have seen some clickbaity articles out there suggesting different axes of product management. One prevalent example states categorizes product managers into Builders and Optimizers.1
The essence of this idea is that Builders work in greenfield product development, making cool, new products that nobody has seen before… while Optimizers apply gentle touches to pressure points in the product to hack growth and make the customer journey more effective. Builders are daring visionaries, while Optimizers are analytical, detail-oriented perfectionists (and the authors usually self-identify as Builders). This dichotomy is misleading.
Disclaimer! First, we should examine content on “builders” and “optimizers” through a lens of positive regard, and realize that the writers don’t mean for us to take their articles literally.2
Now that that’s out of the way: classifying product managers as “builders” or “optimizers” imposes a false dichotomy. This framework can be a useful tool to compare and contrast two different and complementary extremes of product management, but don’t let it constrain your potential for growth and maximum impact. The reality of being a product manager is, of course, usually somewhere in the middle between the two axes.
You are not one or the other, “a builder” or “an optimizer.”
“Builder” and “Optimizer” are not identities that define you, but strategies to deploy when effective
❌ Don’t think of “Builder” or “Optimizer” as identities, or as fixed qualities inherent to your capabilities or that define your career prospects as a PM.
✅ Instead, think of Building and Optimizing as strategies to wield at any time in a battle - one sometimes being more suitable against an opponent (or a problem to solve) than the other.
You’ve probably been (or will be) both, depending on your context. And you can change tactics whenever it suits your needs. Here’s the oversimplified tl;dr -
When optimizing, you already have some kind of functional product with customers and focus on improving and finetuning what’s there. Maybe you are solving a problem you already solve, but in a different way than before.
When building, you are solving a new problem that your product isn’t currently solving for—adding something new.
One isn’t inherently better than or worse than the other. But given your specific context and goals, it may be more effective to wield a building strategy or an optimization strategy, depending on certain factors.
When to build vs. optimize
The short and easy answer is that whatever brings better value for effort is the better solution.
While this might seem like Optimizing, the truth is, sometimes it is more cost-efficient to build anew rather than tweak what’s already there. And as a Smart PM, you are shipping in small iterations, minimizing the cost of any product change whether you’re building or optimizing.
That being said, here are a few factors and conditions that may occur more frequently alongside one strategy than the other:
Stage in the product lifecycle
Early stage → Build. In the early stages, you’re launching a new product or business and need to find product-market fit - this is a classic builder opportunity.
Later stage → Optimize. Whereas for a more mature product, the value-to-effort ratio may be better if you refine existing features, improve the user experience, and optimize in-app journeys to maintain and grow your existing market share.
Strategic aim
New market expansion → Build. If you’re looking to expand into a new market, building may be the answer to deliver a new solution and stand out against current competitors and existing players in your new market.
Of course, optimizing by repackaging and repositioning what you already have could be an answer - especially if you’re launching new capabilities under the umbrella of your current product, rather than as a separate brand.
“Innovation” → Build. Is your company prioritizing innovation as a strategic aim? Are there new technologies emerging that will transform your industry, and you need to understand how to work with them? Or maybe you’re on a team tasked with new product development, R&D, or even loonshots? If so, your job is to build and test and build and test new products - and we’ll get into that in a future post.
Efficiency (aka belt-tightening) → Optimize. Work with what you’ve got, and avoid accumulating new maintenance costs through new feature development.
Scaling (addressing current or anticipated performance issues) → Optimize. Improving performance and efficiency of your product to improve loading times, reduce customer pains, prepare for a growing user base.
Resource availability
Did you just complete a round of funding? → Build!
But again, whichever strategy gives better value for effort is the better solution.
Your PM role
Growth PMs tend to optimize, though this is not an absolute truth.
Role tenure. The duration of your stay on your team or of your initiative timebox can make a difference. Are you a new joiner in a full-time role? Maybe you want to optimize and make smaller-scale experiments while you develop your customer understanding. Once you you know your way around the product and business, you may have a better understanding of build opportunities.
Your own interests. I know, I just spent ~800 words talking about how building and optimizing are interchangeable weapons to pick up or put down. But you can spend some time intentionally honing your skills with one or the other.
I used to work in an early-stage startup and joined a mature team in a later-stage startup, planning to learn more about optimizing. And quickly found myself building again. 🙂
How to find opportunities to practice one type of craft over the other? Well—
You are already doing both; position according to your career interests
What matters in your product management career is customer and business outcome; how you get there is trivial. Most changes involve some degree of both building AND optimizing, and you can frame them as whatever is more useful to your professional interests. Here are some examples of changes that could be sold as a building OR optimizing job:
Replacing a rules-based system with a machine learning model
🏗️Build perspective: You built a new machine learning system!
✨Optimize perspective: You attained the same or better performance, but the machine learning approach is better able to generalize to more situations, reducing maintenance work in the long term.
Improving the growth and checkout funnel
🏗️Build perspective: You developed a new pricing strategy and built a new checkout flow 🤓
✨Optimize perspective: You streamlined the plans page and checkout experience, decreasing dropoff by 3%
A UX revamp
🏗️Build perspective: You introduced a new dashboard with clear actions for users to take
✨Optimize perspective: You simplified the app navigation, reducing obstacles to x and y critical activation steps….
Every piece of product management guidance comes down to “it depends” and “context matters.” What are your goals and needs - as a business, and as a professional? Are you trying to tell a story of your career to be placed for more building opportunities? This is the only time it makes sense to call yourself a builder or an optimizer.
Otherwise, enjoy and make use of build and optimize strategies as part of your PM toolkit.
💡What do you think? Are there parts of this post to which you would raise an alternate viewpoint?
Another variation introduces a third category of “Innovators,” implying that everyone else is a carbon-copying hack :’)
The writers are product managers with a wealth of experience and great lessons to impart—there’s even one article from PM thought leader Sachin Rekhi. It isn’t likely that the authors truly believe in the bucketing—after all, the first rule of product management is probably “context matters.” Let’s attribute the presentation of “builders” and “optimizers” to the realities of today’s content cycle, which requires some simplification, even clickbait-style framing, to be published, reach audiences, and sucker readers like us into clicking to see which one we identify more as.