How to Use Dual-Track Agile Product Development in Early-Stage Startups

When building products, it’s notoriously easy to get the process wrong. As I mentioned in my article introducing the OAK’S LAB product principles, product teams needs to be focused on outcomes over outputs, so whatever process you use needs to get you to the outcomes you want. This is particularly true of early-stage startups, who are often in a race against runway to get to product-market fit or a certain level of traction to unlock the next funding round at X valuation. 

It’s 2023 and everyone wants to be “agile.” But in this high-pressure environment, it’s easy for early-stage startups to fall into one of the following buckets:

• ‍No process at all - Without a product leader, there might be no methodology guiding how the team gathers insights from the product’s users, prioritizes new features, and delivers quality software. Unless you have an elite team, this will result in building the wrong things.‍
• Reverting to waterfall - Often strong, non-technical founders who don’t have product experience will have the exact product that they want to build in their heads. They will request all of these features with their team without incremental discovery work to validate that users will really use and pay for these features. The team will then revert to a linear, sequential waterfall product development process, which can result in large amounts of money spent on building features that customers simply never use - a killer for early-stage startups with limited resources. ‍
• Overcomplicating processes - It’s also easy to fall the other way. Some product leaders who have worked in larger product organizations might have been used to creating structured, repeatable processes that scale across an entire enterprise. In reality, with a small startup team, processes such as these can slow down the development cycle. 

With these potential pitfalls in mind, at OAK’S LAB we’ve identified dual-track agile as the process that best suits the vast majority of founders that we work with.

‍

What is Dual-Track Agile? 

Historically, software development was operated in a “Waterfall” process, where all of the discovery work was done in an initial period of a few weeks or months, before the product was designed and then delivered. This methodology is still used in many enterprise environments, but in a startup environment, it can be extremely dangerous. Although many non-technical founders are incredible product visionaries, the chances that they know exactly what their users want is extremely unlikely. If they’re incorrect in their assumptions, and then commit to waterfall, this can frequently result in features that are never used. 

Continuous discovery throughout the process can help mitigate against this risk by validating your ideas with users. For some context, I’ve personally worked with over 30 startups at OAK’S LAB, and I’ve never seen a product that hasn’t significantly changed scope within the first few months after running the project through the discovery track. 

Dual-track agile is the process of running discovery and delivery activities simultaneously across a project’s lifetime, following the agile development framework that aims at data-driven, iterative, and rapid development. So, what are discovery and delivery? 

Discovery

The goal of the discovery track is to identify what we should be building for our users and our business. As a founder, it can be difficult to focus on anything that isn’t directly contributing to developing a feature, but I would argue that additional focus on these activities is more beneficial than spending time in the delivery track. During the discovery track, here are some of the activities you can expect: 

• Business Goals:  Goal-setting to understand what outcomes you want to achieve. This could be revenue-based, acquisition-based, or retention-based. Setting these goals well is vital as your goals should drive all of the following activities.
• Insights: Gathering quantitative and qualitative insights in the form of user interviews, surveys and analyzing core product metrics. The focus here is on understanding what problems are valuable for us to solve. 
• Scope Discovery: Once we understand the user’s problems. We need to find ways to solve them in the product. Typically at this stage we’ll be conducting activities such as: wireframing & usability testing, business process mapping, user story mapping, impact mapping, assessing technical feasibility, creating high-fidelity designs and prototypes‍
• Initial Estimation & Prioritization: All of the above activities will get us to a set of features which we could build, so it’s important to prioritize by calculating the business impact and effort of each activity.‍
• Product Roadmap: Prioritization allows you to begin to formulate a roadmap for when certain features will be delivered. The roadmap will be iterative and will likely keep changing throughout the course of a project. ‍
• Refinement: This involves breaking down the business requirements in the form of user stories into more specific, actionable technical specifications that the team can work on. 

Delivery

The goal of the delivery track is to take the learnings from the discovery track and build and release as many features that deliver value to the user as possible during a sprint. This typically involves:

• Engineering: Developing the features within the chosen tech stack.
• QA: Running end-to-end, unit, and automated tests on the software to ensure it meets our bar of quality.
• Release & Maintenance: Releasing and maitaining software in a production environment, and ensuring all relevant stakeholders are informed about the release. 

‍

How Dual-Track Agile works within the OAK’S LAB WAY

Sprints 

At OAK’S LAB, we operate on two-week sprints, during which discovery and delivery activities are performed simultaneously. Whilst the engineers are primarily working on delivering already-refined user stories and development tasks, the Product Manager, Tech Lead, and Design Lead will be working on discovering work for upcoming sprints to ensure we can build the right features as fast as possible.

The Foundation Phase

When we kick off a project, we’re typically starting with a smaller team. We don’t yet know the full project scope, and there is a lot of discovery work that needs to happen to decide what our focus should be. For this reason, we start all projects with a “Foundation” phase during which we’ll be working exclusively on discovery activities. Depending on the scope and complexity of the project, this could be anywhere from 2-8 weeks. 

‍

4 Tips for Dual-Track Agile Product Development

Even teams that claim to be agile are often “AINO”, or Agile In Name Only. This is because committing to this methodology sometimes requires a shift in mindset and focus. Here are some tips we have at OAK’S LAB to help the founders and product leaders we work with:

1. Be prepared to work on discovery tasks. As an early-stage founder, you should be prepared to get as much information as possible to help you and the product team make quality decisions. This might involve sharing the results of sales discovery calls, running user interviews independently, or getting access to a competitor’s platform to conduct research. If you think you know everything and don’t need to do this work, you’ll likely end up building the wrong thing. 

2. Have a meeting cadence which allows time for discovery. If you have an engineering team who are able to build quality software with good QA processes, your time spent in the delivery track should be minimal. Try to make sure your time with the product team is spent primarily on the discovery track, so that they can focus on the most impactful things in upcoming sprints. If you take a look at a typical OAK’S LAB sprint schedule, you can see the vast majority of meetings our founders attend are focused on discovery. Stay tuned for a future article that dives into the topic.

3. Give your product time to breathe. I see so many founders at the pre-product stage who have shared a P&L which shows them getting to revenue immediately upon the product’s release. I understand this is sometimes necessary to raise capital. But, whilst possible, it’s rare and puts a lot of pressure on the quality of your first release. It’s important to accept that it might take some time to discover exactly what your users will pay for, and putting financial pressure on the team can sometimes remove the ability to be creative and find the best solutions. In practice, this means extending runway for longer than you think and avoiding scaling other roles until you’re sure you have product-market fit. 

4. Discovery is situational. There will be times where the work on the discovery track is more intense than others. If you’re heading up to a pre-defined “big-bang” release with a relatively large feature-set, it might make sense to be much more focused on delivery than discovery during a sprint to ensure the quality of release. At the same time, if you’ve got an idea for a huge new product component or pivot, you can expect to spend much more time on discovery activities to ensure you’re building the right thing.

‍

Ultimately, a good product development process should be supporting the business’ goals. With dual-track agile, we believe we give our teams the best chance of success by allowing them to stay relentlessly focused on the most important things.