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.
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.
- Time spent building a product is the most cost-intensive time
- Building and validating a prototype can be fairly easy
- Building a well-tested, complex system is difficult
- Making changes after software is built and deployed is costly
- We’re trying to engender release-early, release-often into our culture
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.
- What problem does the product/feature solve?
- Who are the customers/users?
- What are the business benefits?
This is where we try and figure out what the right product is for our users, which should incorporate the following:
- Customer Feedback
- Input from Sales/Marketing
- Competitor Analysis
- Lean Canvas
- What is the right user experience?
- What functionality should the product/feature provide?
- How should the product/feature be built?
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:
- Name of the Product/Feature
- Target Group/Segment
- “Big Picture”
- User Experience
- User Journeys
- Click-through Prototypes
- Product/Feature Details
- User Stories
- Timescales/Release Date(s)
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:
- Static Demo Site
- Physical (i.e. paper) design
- Front-End Development
- Back-End Development
- Underlying Tech
- User Journeys
- Bug Fixes
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:
- Growth: New products and/or features aimed at growing our customer base and increasing our reach
- Revenue: New products and/or features expected to increase revenue for the business through new sales/upsells etc
- Retention: New products and/or features aimed at increasing the retention of our existing customer base
- Engagement: Improvements to existing features/functionality to increase engagement with our existing customer base
- Performance: Under-the-hood enhancements designed to improve the overall performance of our products and/or features
- Satisfaction: Improvements to existing features/functionality designed to delight our existing customer base and increase satisfaction
- Integrations: Integrations with 3rd party systems used by our customers to make our products and/or features more “sticky”
- Partnerships: New products and/or features that specifically relate to partnerships with other commercial and/or charitable organisations
- Operations: Enhancements to our products and/or features that help improve our internal operational processes
- Other: Anything we’re working on that doesn’t fit into one of the other buckets but still needs to be tracked on our Roadmap
Feature Prioritisation: MoSCoW Method
All user stories/features are prioritised using the MoSCoW Method:
- Must Have
- Should Have
- Could Have
- Want (But Won’t Get)
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:
- New Idea (ProdPad): Feature ideas that have been raised with the Product Team but haven’t yet been reviewed
- Opportunity Backlog (ProdPad): Ideas/features that have been reviewed and attached to their relevant theme on the Roadmap
- Development Backlog (Trello): Ideas/features that we’ve committed to building within the next ~6 weeks
- Selected for Development (Trello): Ideas/features that are next up on the development list
- In Progress (Trello): Ideas/features that the Development Team are currently working on
- In QA (Trello): Ideas/features that have been pushed to staging and are being tested/reviewed by QA
- In Review (Trello): Ideas/features that have been pushed to production and are awaiting post-release validation
- Done (Trello / ProdPad): Ideas/features that we’ve built, released and are being used by customers
- Not Doing (Trello / ProdPad): Ideas/features that have been reviewed and we’ve decided not to build (yet, anyway)
Ticket Types: Tickets in the Development Backlog are assigned one of the following labels:
- Feature: New feature development
- Enhancement: Improvement to an existing feature
- Defect: a bug/issue with an existing feature
- Task: Something that needs to be done (but isn’t a feature, enhancement or defect)
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
- Daily Standup
- Weekly Product Review
- Monthly Product Strategy Meeting
- Quarterly Objectives & Key Results Meeting