The development discipline is responsible for producing technology solutions. They define the system architecture and run the software development. Additionally, the team also provides tech expertise on product feasibility in the early phases.
To start the Validation phase, we first need to come up with a strong Product / Service / Venture concept (or multiple), which we will validate in the market through experimentation. This is the Concepting phase, which is creative in nature.
Through different stages, we will create strong concepts:
Opportunity Unpacking: Aligning the Validation team on context and content
How Might We’s: Framing the boundaries of the Solution Space
Idea Generation: Coming up with solution ideas for the problems we framed
Idea Shortlisting: Narrowing down the field of ideas to a manageable level
Concept Cards: Creating comprehensive Product / Service / Venture concepts
Concept Improvement: Challenging and strengthening the concepts
Strategic Business Criteria: Agreeing on how we will make choices
Concept Selection: Choosing which concept(s) to move into Experimentation with
After we know which solution concept(s) we want to validate, we need to understand the key assumptions and risks within those, formulate precise experiments to tackle those and formulate an experimentation plan to guide the team.
To design and plan experiments, we will go through the following:
Concept Critique: Finding the hidden assumptions and risks in a concept.
Assumption Mapping: Evaluating, scoring, and mapping the assumptions.
Experiment Design & Selection: Finding ways to test hypotheses and deciding on experiments to run.
Interpretation Criteria: Setting how we will evaluate the experiment outcomes.
Experimentation Plan: Batching experiments into sprints to run agile experimentation.
Either at the end of our experimentation plan or once we have learned something that very much changes our view on reality and requires a comprehensive review of the concept, we will come to the Concept Review phase, where key decisions regarding the concept are made based on the gathered data.
During Concept Review, we look at the experiment outcomes and learnings and decide:
Iterate: Do we need to adjust the concept or aspects of the concept in tactical (operational/execution-focused) ways?
Pivot: Do we need to adjust the concept or aspects of the concept in strategic (planning/reasoning/vision-focused) ways?
Persevere: Shall we stay with our concept or aspects of our concept as it is / as they are?
Abandon: Do we need to completely abandon our concept?
Once we have wrapped up our Experimentation Sprints and have iterated/pivoted the concept into its final stage, we are ready to compile key business, product, and strategy artefacts, which will be vital for the Production of the concept.
To wrap up the Validation and compile all key outcomes, we will look at the following:
Product Vision: Defining the short-term and long-term vision for our offering
MVP Definition: Setting the first version we need to build to appeal to a first set of customers
Business Model Design: Deciding how we will generate revenue
Go-To-Market Strategy: Deciding how we will address and acquire customers
To-Be Customer Journey: Designing the experience of customers with us
Business Model Canvas: Making integrated strategic choices to set a coherent operation
Implementation Roadmap: Defining what will be done, how, in what order by whom
Business Case: Analysing the financial perspective on our concept over time
Pitch Deck: Creating a compelling narrative to explain the concept to stakeholders and investors
After running through the validation phase, it’s time to share the results with different teams across business, product, development, and operation. We unpack all analysis details to bring stakeholders to the same page, decide and align why & what to build, how we collaborate with limited resources, and get it done.
This is a critical preparation before starting the production:
Business Requirements Document: Demonstrating business case, business value, customer insights, product vision & purpose, and validation results
Alignment & Handover for Production: Bringing all teams (business, design, product, development) to the same page on business context and handover necessary knowledge about the product, customers, and other business rationals
Requirements analysis is the process of modelling the requirements and designs based on the business research findings, validating and verifying the models, identifying the solution options, and assessing the potential value each option could bring to the business.
By discussing the activities for business analysis, we will get to know the following:
Requirements Modelling: Abstract the core needs and create the model based on that
Requirement Verification: Ensure that the requirements and designs modelled are in enough detail and high quality to be used by the relevant stakeholders
Implementation Feasibility Assessment: Assess if the organisation owns the capabilities and capacity to complete the product or features as designed
When the requirements come into being through research and analysis, defining the product solution is the basis for implementing a feasible product that can meet the requirements.
To define the solution, you need to create the following first:
Solution Options Analysis: Define the most beneficial solutions, and assess the business value associated.
Product Roadmap: Help communicate with key stakeholders on high-level tasks and goals in a planned timeline manner
User Roles: Sort out all user roles of the system, making sure the system can close the logic loop and provide must-have services
Feature Tree: Map out the critical features for a thorough understanding of the system modules
Technical Architecture: Design the framework to implement the digital product
As agile methodologies are widely applied in digital projects, iterations are efficient ways to test and adapt quickly. It would be best if you were careful when defining the scope of each version and its iteration about the short and long-term goals.
Defining a version requires the following work to be done accordingly:
MVP Scope Definition: Minimal scope of features to go to the market and validate the ideas
User Stories: Depict the detailed requirements and acceptance criteria to fulfil the product vision
Sprint Breakdown: Planning process and a smaller unit of version definition, which finally forms a deliverable version
Timeline: Timelines work as the plan, the goal, and the reminder that a deliverable is associated with a specified timeframe
Tech startup is the preparation from the technical perspective before the concrete implementation work starts.
In general, these are what could be done for a tech startup:
Legacy Solution Evaluation: It is usually needed in the case where any previous solutions may impact a product
Effort Estimation: Reflect if building the product is cost-effective and reveals any limitations the market may place on the production efficiency
Team Setup: Determine the roles and responsibilities in the aspect of both soft and hard skills needed to create the product and choose the right members for the roles
Environment Setup and CI/CD: Introduces the preparation work before starting implementation and how to efficiently bridge the gaps between development and operation activities during implementation
Kickoff is the official ‘Go’ to the project, which communicates the project background and goals and helps team members and key stakeholders know the RACI of the project. Sprint 0 is the systematical understanding based on the knowledge from the kickoff.
Here are the most critical tasks in this phase:
System Understanding: Help the team learn the big picture of the industry, business objectives, primary problems to solve, etc
Roles & Responsibilities: Every team member must know their position and job to keep the big wheel of the project rolling at high speed.
Dependency Analysis: Always check and foresee the dependencies and potential risks.
Scrum is a topic that has been discussed previously in digital product development. It enables the project to quick turns when adjustments are needed.
Here we only discuss some key points that need to be emphasised:
Scrum Activities: Besides the most common five scrum activities, more activities are introduced in this section.
Design Review: Iterate designs as per the product requirements and technical feedback
Dependency Resolution: Summarise the dependencies identified and also follow up on the action items until the road blockers are removed from the timeline
Retrospectives: Remind the team not to wait for meetings to solve issues but initiate them as long as needed
With users on the product and data coming in, we need to ensure that we have the proper methods and rituals to look at that data in ways that helps us make good iteration decisions early on and move toward the coveted product-market fit. This is where we close the feedback loop and fully implement the lean build-measure-learn cycle.
The main activities that are needed to close the feedback loop correctly:
Data Performance Review: Review the data collected as per the predefined measurements and understand the areas that need to improve
Audience Analysis: Match the reality of actual users against the ideal world of personas and get a better understanding of the target audience
Product-Market Fit: Understand whether the product you have created is a strong fit for the JTBD you want to solve and the target audience using it
While we can keep running many of the rituals from the production process still during Support & Scale, some issues arise once we need to iterate on a live product with users in the market. The Iteration Process helps introduce relevant trade-offs and methods to consider and utilize to complement the product process methods in this phase.
Five aspects will be underlined to help the production team focus at the right pace:
Optimising Team Setup: When working with a live product, we need to split resources between support and production; doing that well is critical to high velocity
Service Level Agreement: Every product makes promises to users about availability, uptime, and error resolution - choosing and supporting those promises well is critical to building trust
Definition of Done: Acceptance criteria must be aligned across the team to facilitate the expected deliverables
Change Control & Management: Stakeholders need to audit and agree on the proposed changes before they get transformed into tasks and assigned to relevant owners
Grayscale Release: To mitigate potentially negative impacts of new releases, this is a method only to impact a small and slowly increasing audience at first to catch problems while not many users have been impacted
Once we have achieved a level of product-market fit, we can invest in growing the customer base as we are assured of a positive CAC / LTV ratio and have started to have a flywheel effect. There are different ways of increasing the customer base, which we will explore, and essential methods of managing the requirements that new impulses that come with that growth.
To drive growth and manage it, we will look at the following:
Product Growth Models: Growing the right way depending on product specifications
User Retention: Ensuring high user retention for growing customer value and LTV
Growth Loops: Building loops of growth and retention that accelerate progress
Requirement Management: Identifying the sources of requirements could help quickly locate and prioritize the most promising features.
Backlog Management: Managing the growing backlog effectively for maximum impact
A/B Testing: Testing different solution options only to implement the best
Communication Rituals: Keeping the information flowing within the company