You Still Need a Product Delivery Framework (Here's Ours)

The Agile Manifesto might advocate individuals and interactions over processes and tools, but that doesn’t mean you should throw them all out the window. Without a framework to help drive product delivery, you’ll waste time scratching around for ideas. Coming up with new products and bringing them to market is a process, after all; you just need to make sure you’re following the right one.

Postit Board


As our team grew to include more developers and designers, we found we wasted time and effort iterating on features throughout the product development life-cycle because we hadn’t clearly defined what we were building, how we were building it, why, and when.

Product Delivery Process

Our product delivery approach is focused around the Lean Startup methodology with the goal to build, measure and learn as quickly as possible. With this in mind, we need to balance the requirements to bring early work to users to try out new ideas with the actual cost of developing and maintaining those features.

Building the Right Things

The first stage of the Product Development Process is to ensure we’re building the right things.

Problem Validation

This is where we try and figure out what the right product is for our users, which should incorporate the following:

Solution Validation

At the end of the “Building the Right Things” phase of Product Development, we'll create a Product Canvas/Product Requirements Document which includes at least some of the following:

There also needs to be a feedback/iteration stage where wireframes and mockups/prototypes are reviewed, amended and signed-off for development.

At the end of the Solution Validation phase, there should be a fully complete, polished concept ready for development. As development is the most cost-intensive time, front-end and back-end development shouldn’t begin before the designs are finalised and signed-off.

Building Things the Right Way

Once we’ve decided what are the right things to build, the next phase of development is to ensure we build things in the right way. Product delivery should encompass the following stages:

Measuring Success

After we’ve released a new product/feature (either as an MVP or finalised product), we need to measure its success. After launch, we need to track the metrics outlined in our Product Canvas/Product Requirements Document and validate our initial hypotheses.

This phase should also include a significant amount of qualitative customer feedback to validate if we have been successful in building the right thing. The output of this will feed directly into the next Problem Validation phase.

Models, Approaches & Tools

Product Roadmap: Current (1–6 Weeks), Near term (1–3 Months), Future (3 Months+)

The Product Roadmap is split into three columns (Current, Near term, Future) with cards based on “themes” (rather than user stories/requirements) which are labelled with the following:

Feature Prioritisation: MoSCoW Method

All user stories/features are prioritised using the MoSCoW Method:

Requirements: Product Canvas; Product Requirement Documents; ProdPad Ideas; Trello Tickets

Product Requirements are documented as part of the Product Canvas /Product Requirement Document for each product/feature. These are then tracked as Ideas attached to the relevant cards within ProdPad. Once we’ve committed to building specific user stories/features and have signed off the expected functionality these are tracked as tickets on the Development Board in Trello.

Workflow: Ideas/features are tracked from start to finish with the following workflow:

Ticket Types: Tickets in the Development Backlog are assigned one of the following labels:

All tickets are linked back to their associated Idea within ProdPad so everyone has visibility of the “theme” each user story belongs to.

Performance Metrics: OKRs

Stretch Objectives & Key Results are defined on a quarterly and monthly basis. All members of the team set their own Objectives & Key Results and share them with everyone, ensuring everyone is contributing towards the same goals.

Delivery Methods: Lean Startup; Kanban

Our preferred delivery methods are Lean Startup (for ensuring we’re building the right things) and Kanban (for making sure we’re building things the right way).

Delivery Metrics: Tickets Closed

Development progress/performance will be measured by the number of tickets closed each week.

Estimation: Trello Tickets

Development timescales will be estimated based on the volume of tickets in the Development Backlog.

Team Improvement: Retros & Standups

Team Standups take place everyday to review progress, measure performance and identify risks/issues and roadblocks. At the end of each development and delivery phase there will be a retrospective which will identify “lessons learned” to be brought into the next phase of development.

Communication: Face-to-face; Slack; Google Hangouts