This week, we reviewed each other’s latest ideas for new areas of the software we want to build. What stands out to me is our lean approach to product iteration. Why do we work this way?

The simple reason: we want to avoid over-designing, over-developing, and getting too attached to ideas that customers may not find valuable. Instead, we aim to focus on our best ideas, leaving the rest on the drawing table. We invest just enough to see if an idea resonates, then move forward based on what we learn. Our goal is to align our product vision with the real needs of the people we serve.

Here are a few ways we keep our product iteration lean:

Lo-fi design concepts

As a designer, I’ve spent too much time perfecting polished concepts, only to scrap them after team feedback. I’ve learned to share scrappier ideas more quickly, more often, so we can figure out where to iterate together. This approach lets us:

• Explore a wider range of ideas. I can sketch many concepts quickly and highlight what’s promising (and what’s not).
• Spend more time on iteration. The best path forward often emerges by combining aspects of ideas from everybody.
• Gather feedback earlier. Developers, customer success, and others offer insights that help us decide which direction is worth pursuing.

Throwaway prototypes

Let’s face it, much of what we build and ship gets replaced over time. At Parabol, this has been true for almost a decade. So why get precious about code or designs? What matters is refining strong ideas.

Lately, we’ve been working on a prototype (one that deserves a post of its own) to explore some next-level concepts. What this unlocks:

• We focus more on how the system works, and less on future-proofing patterns.
• We improve the data model before full implementation.
• We try out UI ideas that wouldn’t fit in production yet.
• We move faster by working outside production constraints.

Minimal first versions

Tying it all together, we aim for minimal first versions. By keeping design concepts and prototypes scrappy, we’re better equipped to define the core of what we want to ship. We ask: what’s the smallest version that lets us validate the idea?

Here’s how we approach it:

• We dream big—on paper, in low-fidelity designs, and in prototypes.
• We imagine all the bells and whistles for the future.
• We identify the core functionality we want to validate.
• We strip it down to an essential first version. We build less up front and learn faster whether or not it delivers real value.

This lean approach helps us ship and learn more often. We get working software in front of customers sooner. The more often we talk with them, the more we understand their problems. We take this learning back into our plans. We save time by discovering what works and what to throw out. And we keep moving forward.

---

Originally published as Parabol Friday Ship #446