In the early stages, finding the balance between speedy development and stable features is crucial. It's important to deliver new features quickly while ensuring the reliability of your app. Let's discuss how we saw it at Kairn.

Build Fast Or Slow?

Navigating the startup world is a mess. You want to be the cool kid on the block, constantly shipping new features, while also being the reliable parent who delivers a quality product. If you're building a SaaS or app, being slow is not an option. Everyone, from users to investors to your team, expects regular updates and improvements. However, rushing development without ensuring stability can lead to technical debt. And that debt has a HORRIBLE compounding interest rate, so don't go there... please.

So to keep pressing we built speedy bets - think of it as channeling your inner Speedy Gonzales 🐭.

When To Embrace Speedy Bets 🐭

Early-stage startups thrive on agility and innovation, and speedy bets play a crucial role in achieving that. Here's when to add them:

a) Quick Market Validation: Speedy bets allow startups to test fun ideas you're not sure will become actual features. The goal is to validate ideas before investing significant time and resources.

b) Competing on trends: By being quick to launch a simplified version of a trending feature you get seen as a frontrunners. See the recent surge in AI-powered features in all SaaS.

c) Motivating the Team: We loved organizing hackathons during team events. Splitting the team into small groups to develop whatever ideas they believed brought value to the app within a short timeframe (1-5 days). Not every feature might be implemented, but every one gets a chance to win the race.

While we'd love to be in speedy mode all the time, building a reliable app is a must. So we tried to create a roadmap that let us incorporate strong building and speedies.

Choosing A Roadmap That Fits Your Delivery Culture

Your roadmap represents your team's plan for delivering features. It reflects your desired balance between speed and stability. Here are three common roadmap types used by early-stage startups:

a) Now, Next, Later: Prioritize features into three buckets - Now (urgent and high-impact), Next (important but not time-critical), and Later (long-term goals). This approach ensures features are shipped when ready without feeling rushed through a specific timeframe.

b) Time-Based: Set specific features to be shipped within a given timeframe (often sprint based - and sprints can go rom a couple of weeks to months). This approach allows startups to maintain a speedy pace, although it can be challenging to implement as features don't always take the estimated time to build. The Shape Up concept, where you cut features down until they fit within the timeline, can be useful for some teams but I am not personally a big fan…

c) No Roadmap: In this approach, individuals prioritise features based on a shared goal. For example, you might focus on improving user retention for a specific quarter and encourage everyone to ship features that contribute to that objective in whatever order they believe is the best. That one is full on democracy 🤷🏽‍♀️.

Mix & Match To Find How To Add Speedies

Achieving the right balance between speedy bets and stable features is crucial for early-stage startups. Consider using a Now/Next/Later framework within a defined timeline, such as a quarter. Set clear PRDs (with design + product) for the Nows, pitches for Nexts, and keep Laters as general idea. Additionally, aim for a balanced allocation of subjects each month, such as 60% on stable features, 20% on speedies, and 20% on bug fixes.

How are you managing this delicate balance in your startup? Wanna discuss it? Ping me.

Cheers,
Pat ♥️