The objective of any product development process is to create a sustainable and scalable pipeline for delivering innovations, either for net-new products or for creating break-through iterations lifting existing products to the next level.

This pipeline is a generic model that can be customized and tailored to any software development organization. This model is based on a Product Team model and uses OKR’s to track their progress and to align efforts across Product Teams.

1. Enhancements & New Ideas

Objective

While ideas can and should come from anyone, its important to not focus on the ideas but the underlying problems they are describing.

Each product team is responsible for ensuring the growth and long-term viability of their product(s), so it is important for the team to never fall in love with an idea but with the problem. When the team is collecting, organizing and maintaining an active list of ideas to improve their product, it is important to frame them as potential problems the team wishes to address.

In order to find the best problems, the product team needs to gather as many ideas as possible, and from as many sources as possible. Externally this could include market research, customer research, and analyst feedback. Internally this could be from primary R&D, design research, sales, and customer support cases, etc. The goal is to find meaningful problems.

Each Product Team is responsible for weighing and prioritizing which problems they want to address as part of the backlog management. Each idea should be assessed against a common framework such as RICE, KANO, or MoSCoW.

Business Considerations

• Business objective alignment

• Leverage tech capabilities

• ROI projections

Technical Considerations

• Sustaining engineering

• Protect the base

• Impact on tech debt

• Improve production efficiency

• Profitably expand program for current populations & clients

• Profitably adapt program for new conditions/ populations

Activities

• Collect ideas in a common space that everyone can access

  • Identify gaps, existing customer needs, and market opportunities as starting point for collecting ideas

  • Include any current market and/or competitive research, including emerging trends for both technological and business

  • Include Customer requests

  • internal R&D efforts

• Run customer and partner co-innovation workshops

• Maintain competitive assessments (including UX, product, technological)

• Prioritize ideas

  • Consolidate and de-duplicate ideas

  • Categorized and organize the ideas, (i.e. by size, risk, competitive advantage, revenue, etc.)

  • The team prioritizes the ideas (i.e. simply voting, ranking systems, brainstorming with other product teams, etc.)

  • Move ideas that do not fit criteria to Parking Lot

Outcomes

• Prioritized list of ideas to move forward with

• Score and prioritize gaps, customer needs, and market opportunities reflective of the overall company strategy

• Check against OKRs for potential alignment and connections

• Identify which items could/should leverage Customer Co-Innovation

• Move ideas that do not fit criteria to a parking lot

Keep in mind at this point ideas have no inherent value beyond pointing to an underlying problem. During Discovery & Research the team will endeavor to understand if a.) the problem is real, b.) and assuming it is real, how valuable is solving it to customers, and c.) what types of solutions are most likely to be feasible and cost effective to develop.

2. Discovery & Research

Objective

Once the team has identified the problem(s) they want to address, it is time to dive in and get a deep understanding of the problem. The goal is to understand the problem from multiple points of view; there is the user’s POV of course but its also important to to put the problem into context relative to the customer organizations, sales, support, market trends, etc. To do this the team will need to create a research plan. The plan should include things such as:

• Observational and qualitative interviews with multiple customers, analysts, industry thought leaders, etc.

• Generative Research for new solutions

• Adjacent & Analogous product research

• Benchmarking for existing products

• Surveys and quantifiable research

• Evaluative research including competitive benchmarking

• Explore potential technologies/architectures including deep dives into emerging technologies, new tools, frameworks, etc.

Activities

• To do this work, the core Product Team will need to establish cross-functional team (i.e., Engineering, QA, Docs, Marketing, etc.)

  • Everyone on the team should participate in the Discovery process.

• Discovery

  • Recruit participants for observational and qualitative interviews

    • Note this will require people from multiple customers

    • The team should also interview analysts, industry thought leaders, etc.

  • Generative Research

    • Adjacent & Analogous product research

    • Benchmarking for existing products

  • Evaluative Research - benchmarking

    • Competitive Analysis

    • Market assessment

  • Customer co-innovation to define needs and problems

    • Understand their needs, expectations, metrics, and previous solutions, workflows, tools, etc.

    • Explore potential technologies/architectures

    • Identify new workflows, tools, frameworks, etc.

    • Deep dive into emerging technologies (i.e. GenAI) and their potential role in developing a solution

  • Summary of the insights, opportunities, and potential solutions

• Research

  • Business Considerations

    • Business objective alignment

    • Leverage tech capabilities

    • ROI projections

    • Profitably expand program for current populations & clients

    • Profitably adapt program for new conditions/ populations

  • Technical Considerations

    • Feasibility assessment, architectural impacts, and consideration for tec debt.

    • Technical explorations & experiments

    • Performance and stability risks

    • Impact on production efficiency

    • In-house expertise regarding any emerging technologies or frameworks

• Note: If during the course of discovery or research there is either a dependency or impact on an existing OKR, that needs to be validated and aligned with that existing OKR.

Outcomes

• Clear POV on the opportunity to be capture in the 6-Pager (Depending on the scope of the idea a new 6-Pager may not be required in which case the team will need to update their existing 6-Pager.)

  • This should include clear articulation of the business impact(s) and customer value including revenue, market share, customer growth.

  • Additionally any potential implications for the product portfolio and any technical risks/implications, etc.

  • Hypothesis of competitive impact

  • Prioritized set of issues that need to be addressed to deliver a successful solution

  • Placement within the product portfolio, touch points with other products, etc.

• Initial requirements for the product, user experience and technology including any specific engineering limitations or design principles, including:

  • Initial Use cases

  • Sketches for the architecture, user experience, etc.

  • Idea, concepts, etc.

  • User Task flows

  • Customer Journey Map(s) by role

  • Refined User Task Flows

3. Design & Prototype

Objective

The outcome for this phase is for the team to produce candidate solutions for addressing the problem. To do this, and using the results from the Discovery and Research as guardrails, the team will rapidly iterate between coming up with potential solutions and assessing those solutions. This will help ensure their ideas in fact solve the most important problems, and their solutions have the right balance between innovation and risk before moving on to plan, build and deploy their solution(s).

The creation of the solutions is best achieved by both facilitated in formal brainstorming sessions, and individual ideation time allowing the team diverge and converge their thinking while allowing for inspiration and personal exploration of the problem.

When assessing candidates, the team should focus on how to best de-risk the development by only promoting solutions that address the following:

• Usability Risk: is the solution is usable, useful, and easy to learn?

• Feasibility Risk: can it be built in a timely manner? Will it impact tech debt?

• Viability Risk: will the final solution fulfill its role in the company’s strategy?

• Value Risk: does the solution provide enough value to make customers spend money for it?

Prototypes can range from simple low-fi, paper prototypes and mock-up, through click-throughs, to working code running canned data. The purpose for prototypes is two-fold: first to help ensure the team’s expectations are aligned for what the solution entails, and second to collect user and stakeholder feedback to refine and improve the solution.

The validation step is completed only when the team is confident that their planned product will create the outcomes that users, customers, and businesses seek.

Activities

• Ideation

  • Multiple, facilitated creative solutioning sessions (a.k.a., brainstorming)

  • Solo ideation time

  • Multiple customer co-innovation sessions

  • Technical R&D spikes and experiments

• Prototyping

  • Low-fi paper prototypes → to working code with canned data.

  • Collect user and stakeholder feedback

  • Rapid iterations based on results

• Validation & Iteration of the prototype(s)

  • Usability impact assessment

    • Review prototypes with users, customers, partners, sales, support, and other stakeholders

    • Run 1:1 usability studies

  • Technical impact assessment

    • Vet prototypes for technical feasibility with the larger engineering organization

  • Refinement of use cases, business case, and technical implications and feasibility based on the various assessments

  • If necessary cycle back to do more discovery & research

• Leadership team review

Outcomes

• 6-Pager

  • Market fit assessments

  • Competitive differentiation

  • Define detailed business case, with customer benefits, including clear statement of what the solution will NOT deliver

  • Relevant market history leading to the current situation, resulting the emergence of the problem(s) and opportunity(s)

  • Packaging and Pricing recommendations

  • Long-term strategic implications

• Clear set of product requirements, initial UX designs, and a implementation plan/architecture (Note: these will be refined to reflect the realities of development.)

• Draft MVP roadmap, staw-man release plans for the first two quarters

  • Initial set of user stories have been prioritized and have estimated in story points

  • A User Role/Persona have been tied to each story

• Initial draft OKR’s tied into Company level OKRs, including:

  • Metrics & Performance targets

  • Success criteria are defined

• Clear Definition of Ready, including:

  • Feature acceptance criteria is defined and documented

  • Initial wireframes completed

  • And epic has been defined

  • Metrics & Performance targets

  • Acceptance criteria including non-functional requirements

  • Detailed product requirements including NFR

• Approval to move forward with the solution(s) for development

  • This could be determined by the product team for small enhancements or require leadership to move larger initiatives forward

  • For net-new solutions the executive team will review and approve the establishment of any new products on behalf of the business.

4. Plan, Build, & Deploy

Objective

Once a solution has been approved for development the team will need to define their long-term and near term (quarterly) roadmaps to plan their development of the product/service, including critical dependencies, milestones, etc.

Activities

• Prioritize the product plan including designs, customer feedback, business case, and metrics

• Syndicate the plan with other teams (i.e. documentation, customer success, customer support, marketing, sales, etc.) to ensure their vision, deliverables and timelines are aligned with other functions and other development efforts.

• Quarterly planning

  • Product teams will create a theme for their quarter and define a set of OKRs for the quarter (see OKR Process

  • Well defined set of epics and high-level user stories

  • These meetings will focus on the Triad’s Quarterly OKRs and are NOT walk-throughs of the Triad’s epics or high-level user stories.

  • Detailed UX design specifications including wireframes, workflows and design mock-ups

  • Documentation plans for instructional material and in-app help

  • Go-to-Market plans, messaging, sales readiness, etc.

• Monthly planning

  • Provide leadership updates on OKRs, focusing on their delivery against their Key Results

  • For any issues or blockers, the team should review their mitigations and discuss any implications for their delivery, as well as dependencies from other teams

  • Likewise any updates or adjustments to their key results or other metrics need to be reviewed

• Sprint Planning

  • Break down epics to stories, including sizing, dependencies, and any required spikes

  • Backlog prioritization, include any required clarification, design,

  • Detailed engineering planning: how the feature/solution will be built, including architectural, data, or infrastructure implications

  • Test plans, automated testing or partial automated testing, and their impact

• Development

  • Development, test plan creation, code reviews

  • Feature test execution

  • Complete and review test plans

  • Sprint demos

  • Deployment details or dependencies

  • Dev to QA handover readiness

  • QA execute test cases, regression testing, bug closures, etc.

  • Define QA testing targets for:

    • Unit test coverage

    • Automated test coverage

    • Documentation

    • Training

    • Support

Outcomes

• A clear quarterly plan with OKRs

• Leadership sign-off go/no go on the plan

• Any action items for specific development teams to track or report back on.

• Identify dependencies for other development teams

• Plans/timelines from Documentation, Training, CSM, Support, etc.

• High level dependencies list, e.g., epic and feature level

• Prioritized backlog of stories with sizing to optimize resource

• Breakout development tickets, with the initial assignments

• Story level dependency list

• Alignment across product teams to balance resources, release dates, alignment on external messaging, go-to-market plans, etc.

• Identify issues for A/B testing of the product

• Define product instrumentation to track utilization metrics post launch

• Updated 6-Pager with any changes to the direction, scope, metrics, etc. Additionally capturing any open issues that need to be addressed.

• Eventually the team will need to check their delivery against their Key Results, if they have delivered their Key Results they have achieved their Objective

  • The team will also need to define their operational objectives and SLA (i.e. five-9’s,

• Define acceptance criteria including

  • Performance and all conditions

  • Functional completeness

  • User Experience performance, completeness, fit and finish

  • Confirm product meets the business requirements

  • Produced code for presumed functionalities

  • Product/Capability deployed on a test environment identical to customer’s production environment

  • The performance tests passed

  • All bugs fixed

5. Maintain and Improve

Objective

Operate the product, platform and services to meet or exceed the team’s established service level agreement

Activities

• For Key Results assessing impacts on customer behavior will continue to be tracked and reported on.

  • Again the Objective cannot be consider completed until the required Key Results are delivered.

• Release notes are written and communicated to the relevant teams

• Test release candidate builds

• UAT environment setup, when applicable

• Security vulnerability scan

• Leverage instrumentation to understand both utilization, time on task, iterations, etc. for pipeline creation

• Data Science will capture the intent behind the pipelines to enhance our ML capabilities

• Data Science will continuously improve our recommendations/ML capabilities

• Using instrumentation, the team will make determinations for removing features, functionality or services no longer used by customers

• Looking toward future releases, the team will develop migration plans for moving customers from legacy solutions to current release

Outcomes

• Regular performance reports with key features, functionality and services broken out by customer, industry, roles, etc.

• Recommendations to EOL features, functionality, or services

• Migration plans for future releases

• Code moved to production

Note

Based on the Amazon 6-Pager, who’s long format forces the writer to think more deeply about the problem than say a set of bullets in a PowerPoint, the purpose is to capture in one place the intent and scope, and implications for new projects and products. 6-Pagers follow a common outline:

• Analyst Report from the Future

• Vision

• Tenets

• State of the business

• Strategy

  • The Problem

  • The Solution

  • Business Expectations

  • Technical Reality

• Appendix

  • Rude FAQ:

  • References:

  • Glossary