The Secret to Faster Product Iteration: Less Is More | Bolt's Pick

Building something people actually need doesn't inherently take a long time. What slows product teams down is usually something else: bloated processes, distance between decision-makers and executors, lengthy spec documents, and so on.

Ned O'Leary, co-founder and CEO of SSOReady (YCW24), recently shared on his blog how his company speeds up product development by cutting requirements, simplifying design, iterating quickly, and buying off-the-shelf solutions.

We've organized and translated the core principles he laid out for rapid product iteration — we hope they give you some food for thought. You can read the original via the link at the end.

01 Less Is More

In product iteration, there's always a trade-off between speed and quality. Most of the time, if you want to go faster, you compromise on quality somewhere. Something always gets cut.

But not all product requirements deserve equal treatment. You can drop the less important ones, have engineers do less, and solve the core problem. When requirements are clear and bounded, engineers can usually build high-quality code much faster.

Most companies set requirements, fix deadlines, and treat quality as an outcome. We tend to do the opposite. We ask ourselves: given a quality standard, what can we ship in 60 days?

02 The Simple Solution Usually Works Better

We're big fans of what the "midwit meme" communicates. Simply put, the meme shows a low-IQ idiot and a genius agreeing on a simple solution, while a person of average intelligence complains about complexity and imagines all kinds of perfect solutions.

In our early days, we challenged ourselves to operate in "idiot" mode as much as possible. When we messed up, it was usually from overthinking. We often found workable solutions by asking ourselves, "What would I do if I were an idiot?"

03 Focus on What Actually Matters

Only a handful of problems are truly important. For example, we have to take security extremely seriously. Absolutely no cutting corners there. But we can choose to ignore other, less critical things. We know our frontend doesn't look great on mobile. For the foreseeable future, we just need customers not to use it on mobile — and nobody really minds.

Obviously, we'd love for our software to look great everywhere, but we choose not to spend more time on desktop layout. And we're definitely not launching a dark mode anytime soon if it delays progress on core problems.

04 Just Ship It

We have no product development process. No Figma prototypes, no PRDs, no design system, no agile, no OKRs. We don't even have a clear product roadmap, and of course, no A/B testing.

The most important thing is to build the thing first, see if people like it, then iterate or improve based on feedback.

05 Rewrite When Necessary

When a product has a lot of legacy code issues, most companies assume they'll move faster by postponing refactoring as long as possible. Sometimes that works, but we prefer to do major rewrites to deal with technical debt at the right moment.

We think the fastest path to building the right product looks like this:

• Write the wrong code
• Realize it's wrong
• Replace the wrong module with the right code

06 Pay for Outsourced Solutions

In some cases, we choose to buy solutions from vendors rather than build internally. For example, we use a vendor called Fern to generate our SDKs, and they do a pretty solid job. Of course, using outsourced services has significant upfront costs — they're usually expensive, and they constrain our freedom to some degree.

Given our engineering costs, paying for outsourced solutions is usually the right call. Our engineering resources are extremely limited and very expensive — about $5,000 per engineer per week. Compared to building in-house what a vendor already does well, we'd rather spend that engineer time on something more valuable.

07 Don't Hire Too Quickly

CEOs shouldn't expect adding headcount to increase team output. Hiring is a slow and difficult process. Onboarding and management consume huge amounts of time. Even employees who've adapted to company culture create additional overhead when collaborating at scale. So despite having the resources to build a large engineering team, we do everything possible to stay small. It makes work and life easier for everyone.

08 Wrapping Up

In the past, we didn't clearly realize that product development shouldn't take that long, and we took many detours. As a startup team, we need to focus on what truly matters in our product and avoid unnecessary complexity — that's the key to shipping fast.

📮 Further Reading

Linear Bolt Bolt is Linear Capital's dedicated investment program for early-stage, global-market-facing AI applications. It carries forward Linear's investment philosophy, focusing on technology-driven transformative projects, with a mission to help founders find the shortest path to their goals. Whether in speed of action or investment approach, Bolt's commitment is lighter, faster, and more flexible. In the first half of 2024, Bolt invested in seven AI application projects including Final Round, Xinguang, Cathoven, Xbuddy, and Midreal.