When Less Is More: Product Strategy in the Push and Pull of Growth

Every product moves through cycles of expansion and contraction. There are times when you're adding features, exploring new bets, and shipping fast. And there are other times when the right move is to step back, clean things up, and tighten the experience. I've worked through both phases and learned that navigating the shift between them is where product judgment really shows. In this article, I want to walk you through the questions we asked ourselves and our thought process when navigating a contraction phase.

Note: This article comes from my experiences at fast moving startups. Our success metric as a team was the rate at which we shipped. Insights from this article will have to be modified to fit different teams.

The temptation to always build

During expansion, it's easy to fall into a mindset of more = progress. More features, more pages, more toggles. But when things get bloated, you risk losing the clarity that made the product good in the first place. That’s where contraction comes in. You zoom out, simplify, and ask: “What’s actually essential?”

But even when you know it's time to simplify, the work doesn't always look like traditional “shipping.” In fact, it can be hard to measure. I stopped asking if users would notice and started asking if they'd feel it. That shift in thinking led to better decisions like trimming down onboarding, removing distractions, or hiding advanced settings until the right moment. They’re all subtle moves, but they add up to an experience that feels clean and intentional.

Success you don’t see

One of the most helpful mindsets I’ve adopted is that good UX often hides itself. It’s not about delight through animations or gradients. It’s about not making users think. In our contraction phase, we leaned into that. We didn’t broadcast every small change. But we did track whether support tickets dropped. Whether user activation rates ticked up. Whether we could remove a help tooltip because users didn’t need it anymore.

That said, not every change could go completely unnoticed. For larger updates, especially those that affected familiar workflows, we used marketing cards. These were simple visuals paired with clear text, often referencing things users had mentioned in interviews or we had identified during product audits. The message was usually something like, "We hear you. We updated this to work better for you." Yes, this was about informing them, but it was also about showing them that we were listening. I’ve noticed it’s small things like this that turn people from customers to vocal fans about the product.

Prioritization is a team sport

Working in a small team means every decision matters. It also means you can’t afford to pull in different directions. So we made prioritization something the whole team had a voice in. We’d align on the phase we were in (expanding or contracting) and then evaluate every idea through that lens.

However, alignment doesn’t happen by accident. As a product manager, it's your job to ask the right questions to steer that conversation. If we were in a contraction phase, I’d ask: What feels bloated? What areas of the product are hardest to explain to a new user? Where do we consistently see confusion or drop-off? These aren’t questions you answer alone; they’re prompts to unlock your team’s intuition. A designer might recall a rushed flow that never got cleaned up. A developer might flag tech debt that’s making everything harder to maintain.

Then you layer in the data. Maybe you’ve noticed a spike in rage clicks on a particular screen. Or support tickets piling up around a feature that’s way too complex for what it’s solving. That combination of team insight and product data is how you make prioritization real. It’s not just gut feel, and it’s not just metrics. It’s both, working together.

From cleaning up to scaling up

Eventually, every team hits a moment where it’s time to shift gears back into expansion. That’s where things can get tricky. How do you build new functionality without undoing all the clarity you just created?

The answer depends on how your company operates. If quality outweighs speed, your UX team will have the space to dig into information architecture, use progressive disclosure, and reduce cognitive load. You’ll ask things like: When will users need this feature? How often? What parts of the flow can we automate? Can we set smart defaults?

But in fast-moving teams like mine, the reality is: you can’t always get it right the first time. Expansion means building fast. UX might find the right moment or placement for a feature eventually, but it won’t be perfect out of the gate, and that’s okay. Spending too much time polishing can actually slow momentum. In these moments, your success metric as a PM isn’t polish. It’s speed. You ship what you can, get it out the door, and make a note to come back during the next contraction phase to optimize it.

Making space for clarity

If I had to summarize what guided us through all this, it’s this: design is communication. When the product feels scattered, the message is unclear. When it’s focused, the value speaks for itself. My time in the startup realm has taught me the importance of stepping back and taking some time to polish.

I won’t pretend to have all the answers. I'm still learning. But these are the decisions that shaped our team. And if there’s one thing I’ve taken away from it all, it’s that growth isn’t just about adding more. Sometimes, it’s about making space for what matters.