#product - 15 mins read

A blueprint for modern product development

At some point, most companies look to standardise how they build things. This typically happens when they grow to a size where communication begins to break down, their concentration of senior people dilutes, or they start focusing more intentionally on impact, quality, and return on investment (ROI).

In some industries – manufacturing, construction – standardisation is well-defined and repeatable. But building software isn't like building car doors. Every requirement is a different shape, sometimes wildly so. We can deliver new features into users' hands multiple times a day, creating a unique opportunity to learn, refine, and deliver value quickly. That's why applying Taylorist principles to product development is a fool's errand.

This poses a challenge for organisations wanting more predictability and confidence in their development process. Many approaches have influenced how we design and build software – from waterfall to agile, DevOps, user-centred design, the double-diamond, test-driven development, and CI/CD (Continuous Integration/Continuous Deployment). The list is endless.

We've landed on this set of steps designed to reduce risk, maximise impact, and streamline time-to-market. Despite the linear-looking diagram, this isn't a rigid, stage-gated process. Modern product development is continuous, iterative, and adaptive, with feedback loops built into every step. The time spent in each phase will vary based on the size and complexity of what you're building, but we believe these steps lay a strong foundation for building successful products.

Having helped many organisations visualise and optimise their product development process, we thought it was time to share our own approach.

Who this blueprint is for

This blueprint is primarily for companies feeling the growing pains of scaling up or those dissatisfied with the impact of their product development efforts.

While these steps and techniques apply to startups too, early-stage companies should optimise for time-to-market. Implementing guardrails and fostering supporting behaviours takes time and effort. In startups, this competes directly with the need to sell and grow, making it difficult to win buy-in for these practices.

Principles

First of all, there are some principles that underpin our product development process:

• Continuous discovery & delivery – Discovery is not a one-time phase but an ongoing practice embedded into everyday work.
• Product engineering – The best product teams don't separate "what to build" from "how to build." Engineers, designers, and PMs co-own solutions from the start.
• Fast, incremental value – Thin, vertical slices of value should be shipped continuously, validated in production, and iterated based on feedback.
• Flow over governance – Minimise handoffs and approvals; empower teams with a clear direction and a set of guardrails.
• Evidence, not opinions – Use data, user research, and real-world experimentation to drive decisions, not HiPPOs (Highest Paid Person's Opinions).

Now they're out of the way, let's dive into the steps and walk through what each one is designed for, what you should and shouldn't do, their inputs and outputs, and who's involved.

The end to end process

Download the full PDF here

1. Capture

We often refer to this step as the 'front door'. It's where opportunities come from, how they're collected, and how they're prioritised.

The Capture step is about creating deliberate channels for opportunities to flow into your product development process. These opportunities come from various sources and in different forms:

• Customer feedback – feature requests, complaints, and support tickets.
• Bugs & technical debt – issues that impact usability, performance, or security.
• Product analytics & observability – insights from user behaviour, adoption metrics, and system health.
• Leadership directives – strategic bets or urgent priorities from executives.
• Sales & customer success requests – features to help close deals or improve retention.
• Competitor moves & market trends – pressures from industry shifts or emerging threats and opportunities.

Best practices

Make sure you're tuned in
Create reliable channels for capturing signals from all parts of your organisation and market. This means regular customer interviews, monitoring analytics, competitor analysis, and ensuring internal teams and customers have clear pathways to submit opportunities.

Conduct proactive exploratory research
Don't just wait for opportunities to come to you. Regularly schedule time for proactive exploration of user needs, market gaps, and technological opportunities.

Anchor to a strong product strategy
Your product strategy should act as a filter, helping you quickly identify which opportunities deserve deeper investigation and which might be interesting but don't align with your direction.

Implement frictionless, consolidated tooling
Whether it's an all-encompassing product management platform like Pendo or ProductPlan, or a well-structured Google Sheet with a form attached, having a single source of truth for capturing and sorting opportunities reduces overhead and prevents valuable insights from slipping through the cracks.

Establish an effective prioritisation process
Even at this early stage, having a lightweight framework for initial prioritisation helps manage the flow of opportunities and prevents your team from being overwhelmed.

Common pitfalls

• Too many signals – Opening up too many intake channels, making it difficult to consolidate and prioritise effectively
• Poor communication and visibility – Not communicating back to submitters, discouraging future contributions
• Too many bypasses – Allowing the loudest voices (often sales or executives) to bypass proper evaluation

Who's involved

Product leaders make key decisions and define direction, but inputs should come from everywhere – customer-facing teams, engineering, design, marketing, and executives all have valuable perspectives.

Inputs & outputs

Inputs: Raw opportunities, customer feedback, market research, analytics insights, competitor moves, technical requirements.

Outputs: A prioritised backlog of opportunities worth exploring in more depth.

A bad front door process can overwhelm your teams with too many opportunities, let in too few signals leaving you reliant on gut feel, or admit the wrong opportunities that don't deliver impact or support your long-term strategy. When done well, a good front door process acts as both filter and funnel, ensuring the right opportunities flow into your product development pipeline.

2. Discovery

Discovery is where you take your promising opportunities through a process of understanding the associated user needs, business opportunities, and technical considerations. Here, you'll refine high-level solutions through prototyping and user testing.

The aim is twofold: reduce the risk of developing something that isn't valuable, feasible, or viable, while preparing solid solutions for development.

We use the term 'Discovery' to encompass both problem and solution exploration, unlike GDS who split these out into two discrete phases: Discovery and Alpha. The reason for this is that we've learned that you often need to create stimuli for users to understand their problem deeper. It also reduces hand-offs that are sometimes introduced when separate teams or individuals conduct Discovery and Alpha.

Best practices

Diverge before you converge
While there will always be budget and time constraints, there's tremendous value in not just picking your first solution and running with it. See Daniel Kahneman's "Thinking, Fast and Slow" for more on how cognitive strain can drive better decision-making. Try out multiple approaches, get them in users' hands, validate them, and select the one that performs best. Your first solution is rarely your best one.

Be led by the evidence
Strive to understand the problem you're aiming to solve as deeply as possible. Use a mix of qualitative and quantitative techniques – customer interviews, user testing, data analysis – to build a comprehensive picture. Refine your solutions regularly with real feedback from the people you're developing for. Map and test your assumptions systematically – they are the enemy of good product development.

Cover all bases
Consider the four main risks in product development: value, viability, feasibility, and usability (though there's less emphasis on this last one at this stage). Ensure you have a cross-functional team working to de-risk these areas and shape the solution. Missing any one of these dimensions can derail even the most promising opportunities.

Avoid gold-plating
We practice continuous discovery – that is, discovery and refinement continue throughout the delivery cycle. You don't need to leave discovery with pixel-perfect prototypes covering every use case, or having spiked every technical unknown. It's about doing enough to either kill an opportunity or confidently move into delivery.

Common pitfalls

• Endless discovery – For new features, aim for 0-4 weeks. For new products, 6-12 weeks. If you're still in discovery after that, you might be overcomplicating things.
• Not being user-driven – Discovery that's based primarily on internal assumptions rarely leads to successful outcomes.
• Trying to be too scientific – You're not going to be able to truly validate hypotheses until you've shipped the real thing.
• Going too high-fidelity – Elaborate prototypes can create sunk cost fallacies and make teams reluctant to pivot.
• Picking the first solution – The path of least resistance is rarely the path to greatest impact.

Who's involved

Discovery is largely the domain of the product trio – a tech lead, the product manager, and a product designer. Depending on the challenge, you may need to pull in more specialist skills – user researchers, service designers, data analysts, legal teams. However, while the product trio should lead, they should collaborate with relevant stakeholders to ensure all perspectives are considered.

Inputs & outputs

Inputs: A prioritised opportunity or problem to solve.

Outputs: Framed problem statements, user needs/jobs to be done, prototypes, story maps, user journey maps, service blueprints, high-level architecture diagrams, user stories, product canvas or PRD, agreement to move into delivery, or in some cases – a business case.

Remember that discovery isn't about perfect documentation or scientifically trying to validate if an opportunity is going to work – it's about reaching sufficient confidence that you're solving the right problem in the right way before committing significant resources to building it.

3. Delivery

Delivery is where you build and refine working software while gathering feedback from users. This is the most expensive part of the product development lifecycle, because engineering time = money. You want a high degree of confidence in the scope and success of the thing you're building before you start, along with an efficient development and release process that optimises time-to-market.

When you've committed to building a solution, this is where you can more actively start engaging support, sales, and marketing to develop your go-to-market plan and ensure they have enough time to prepare.

We call this phase 'Delivery' not 'Development', to emphasise that we are delivering working software, not just building it.

Best practices

Continue discovery in parallel
Discovery doesn't stop when development begins. Keep learning about your users, market, and technical constraints as you build as well as refining stories before they're picked up. This allows you to make informed pivots if needed, rather than stubbornly following the original plan when new evidence emerges.

Build thin vertical slices
Rather than building in horizontal layers (e.g., database, then backend, then frontend), aim to build thin vertical slices of functionality that deliver value to users. This approach lets you ship value and learn faster.

Minimise work in progress (WIP)
Focus on getting features all the way to 'done' before starting new ones. Having too many items in progress simultaneously creates context switching, delays feedback, and masks bottlenecks. Aim for flow over utilisation.

Trunk-based development
Avoid long-lived feature branches that lead to painful merges. Encourage daily integration into main/master, using feature flags to hide unfinished work.

Make testing everyone's responsibility
Quality isn't just QA's responsibility. Engineers should be responsible for writing tests (unit, integration, and end-to-end), product managers should validate user stories, and designers should verify implementations. Shifting quality left prevents expensive rework later.

Implement blue/green deployments
Use deployment strategies that minimise risk and downtime. Blue/green deployments let you validate new versions in production environments before directing traffic to them, reducing the impact of potential issues.

Establish clear definitions of 'ready' and 'done'
Before starting development, ensure everyone agrees on what 'ready' and 'done' means for each feature. This prevents scope creep and ensures nothing important gets overlooked in the rush to deliver.

Automate where it makes sense
From testing to deployment to monitoring, automation can reduce human error, speed up processes, and let your team focus on high-value work rather than repetitive tasks. But be strategic about what you automate – not everything needs or benefits from automation.

Common pitfalls

• Poor quality – Rushing to deliver features without sufficient testing leading to technical debt and user frustration.
• Long lead times – Taking too much time to get from idea to production means slower learning, less competitive advantage, and, usually, disgruntled stakeholders.
• Bottlenecks in discovery or testing – These create stop-start development cycles and inefficient resource allocation.
• Not releasing regularly enough – Long release cycles mean delayed feedback and increased risk when you do deploy.
• Incurring too much technical debt – Short-term shortcuts often result in long-term slowdowns as complexity compounds.
• Losing sight of the problem you're solving – It's easy to get caught up in implementation details and forget the "why" behind the feature.

Who's involved

Largely engineers. We prefer full-stack/product engineering to minimise handoffs and dependencies. Product managers and designers remain actively involved, as discovery activities continue alongside development. Testing is everyone's responsibility, embedded within the team rather than relying on separate QA roles.

Inputs & outputs

Inputs: Prioritised and validated opportunities, user stories, technical specifications, acceptance criteria.

Outputs: Working software that solves real user problems, deployment pipelines, automated tests, documentation, monitoring tools.

Delivery isn't just about writing code. It's about getting valuable solutions into users' hands as efficiently as possible while maintaining quality standards that support long-term maintainability.

4. Rollout

In our view, rollout is three-fold. The first stage is rolling out your product or feature in a private (closed) beta setting to a set of friendly customers or users. Here, the solution won't be perfect, but you're doing it as early as possible to get real-world feedback.

The second is open beta. This is where you roll out your feature wider, ideally through a phased release process to most, if not all applicable users. Tools like Launch Darkly and Flagsmith can really help here. It's important that you've instrumented your analytics correctly to give you visibility into user behaviour. You will keep a much closer eye on features and products in beta, and aim to measure the impact of it while ironing out any issues.

The third is general availability (ga). Where you roll it out to everyone, with any major issues addressed and user satisfaction is high.

With the support of automated tooling and good upstream processes, this phased rollout can be a matter of days, not weeks or months.

Best practices

Implement a phased rollout
While time-to-market is key, shipping features that have bugs can hurt customer satisfaction and retention. Rolling out to smaller cohorts and increasing from there once you've gained confidence is a sensible approach. Consider techniques like canary releases and ring deployments for larger products.

Don't forget to collect the data
Instrument proper data collection and analytics tied to clear product metrics. Establish baseline metrics before rollout to accurately measure impact. Consider using product analytics platforms that allow for cohort analysis and funnel tracking like PostHog or Amplitude.

Don't fire and forget
You may have instrumented data and analytics collection, but if you're not regularly monitoring them and feeding back issues and impact to relevant stakeholders, you're missing a critical feedback loop. Set up automated alerts for key metrics to catch issues early.

Communicate the readiness to users
Communicating whether a product or feature is in beta or generally available sets users' expectations accordingly and is a good signal to stakeholders how closely you should be monitoring it. Consider using in-product badges or banners to indicate beta status.

Establish feature flags as infrastructure
Treat feature flags as a crucial part of your technical infrastructure, not just a temporary tool. Implement a governance process to prevent flag sprawl and ensure regular clean-up of obsolete flags.

Implement observability beyond just monitoring
Modern practice goes beyond simple dashboards to embracing comprehensive observability. Implement logging, metrics, and tracing that allow you to understand not just what's happening but why it's happening.

Build a feedback loop with customer success
Create structured channels for customer-facing teams to relay user feedback directly to product teams. Set regular review sessions to analyse this feedback alongside product analytics.

Common pitfalls

• Going too wide – Shipping product and features to all users too early that may still have issues.
• Lack of ownership and process – Once a feature is released, it often drops off the product team's preview.
• Moving into a BAU mindset – Assuming a product or feature is done at this point, and missing the opportunity to continually refine.
• Poor communication – Not appropriately setting user expectations.
• Operational readiness gaps – Support, sales, and marketing teams not being prepared to support, sell, and market the product or feature.
• Insufficient rollback planning – Not having a clear strategy for reverting changes if significant issues arise.
• Treating monitoring as an afterthought – Failing to implement proper telemetry before rollout, making it difficult to understand impact.
• Not defining success metrics – Failing to clearly define what success looks like upfront, leading to decision paralysis when monitoring impact.

Who's involved

Product, engineering, DevOps, customer success, support, sales, and marketing all play crucial roles in successful rollouts. Site reliability engineers (SREs) are increasingly important for managing complex rollouts and ensuring system stability.

Inputs & outputs

Inputs: Working software, release strategy, feature flag configuration, monitoring setup

Outputs: Release notes, documentation, training materials, marketing and sales collateral, product analytics, customer feedback, incident reports, performance metrics

Notes on timing and scale

This blueprint should be able to guide product development at a feature level through to a whole product level. Whole products may take months to deliver an MVP or v1. Features can be discovered and delivered in weeks, sometimes days, depending on their complexity and the competency of your team and ways of working.

Here's rough guide on how long you should spend in each phase depending on the scale of the solution:

Summary

Having a well documented product development process can help your whole organisation deliver better products at scale.

The four steps – capture, discover, delivery, and rollout – aim to reduce risk and maximise impact while minimising waste and optimising time-to-market.

They are best suited to scale-ups and enterprises who are facing challenges as a result of their growth or who want a better ROI from their product development efforts.

While they are also applicable to startups, they should be viewed in this context as a target to work towards, while protecting speed and agility.

Finally, and a note of caution, standardisation - when not implemented pragmatically - can stifle morale, agility, and innovation. Don't standardise for its own sake. Be clear about your rationale, and remember that this blueprint is a guide, not a mandate.

If you're looking to document and understand your organisation's product development process better, or are looking to improve how you discover and deliver your products, please get in touch.

Written by Sam Quayle

Co-founder, Director

03 Mar 2025

link