Innovation Process vs Product Portfolio Management

Innovation distinguishes between a leader and a follower – Steve Jobs

I am as proud of the things we have not done as the things we have done. Innovation. Innovation is saying no to a thousand things. – Steve Jobs

Before I define what framework works, I will spend a section on the traditional approach. Then we will detail an appropriate framework for an Innovation Process that allows experiments and mistakes that will drive innovation as Steve Jobs

It is important to understand that the principles of agile does not easily connect with the more traditional view of Investors whether that are external or C-Suite which approves the budget to take a product forward. Agile is not about committing to horizon you cannot predict, but Investors want all the answers at the beginning with a fully formed business case predicting muti-year revenue and development cost.

This traditional framework which Is also termed Product Governance or Product Portfolio Management, which is still very prevalent means that the funding is allocated at the highest risk point – most companies and investors have stage gate process that allows them to pivot or halt the progress of product development to mitigate that high risk.

So, what is the progressive and agile Innovation Process?

To mitigate risk and uncertainty which is one of the benefits of an agile approach it will focus on experiments to identify product market fit. Experiments can be prototypes, surveys, and market testing to reduce the risk and the cost.

I view Product Management quintessential job to search, find and promote new products, services, and business models. This does not mean it is down to the Product Manager, but rather they provide the environment to allow ideas to be fermented whether that is feedback, Customer Advisory Boards, AMA (Ask Me Anything) with customers etc. So that is the starting point and there should be a funnel of ideas that go through the process.

The agile approach is to test concepts and fail fast with least cost and only if it deemed if the decision is made to build the product more budget is assigned. And even then, you can continue to explore the product market fit.

So, the agile approach is to take on idea and gradually validate the product market fit and as you build confidence spend more funds on it.

The Validation ladder is great framework on gradually building confidence especially for Investors and C-Suite.

Agile Innovation Process

It consists of 2 main cycles which depending on resource can run alongside each other.

The first is to take those diverse ideas and decide which to experiement on. The goal is to test ideas early and cheaply.

Who can propose ideas? Everyone in the team. The PO will be the advocate of the idea proposed by anyone in Company and often outside the company. Key is to have closed feedback loop otherwise they will feel ignored and your source of ideas dries up.

When? Regular Portfolio Meetings will decide the priority of Innovation Options along the whole product lifecycle.

There are 2 decision points in agile product development

1.    Experiment

The first to invest in an idea to design and create an experiment to increase market learning. That decision point will also decide to continue experiment to deepen market learning or to bill or kill.

2.    Build

The second is part of the incremental agile building of the product where small increments of investment to add features and scale

Planning B2C vs B2B Roadmaps

B2C

For B2C the users and buyers are often the same. Sales Cycle is shorter and the on-boarding needs to be automated and seamless. The access to users is easier allowing data-driven design decisions. The product needs to be intuitive and able to educate and influence the buyer/user. Retention is also paramount as well as the user engagement - they need to love the product. So, the Product team needs to have process in place to take the data generated by users qualitative and quantitative into their prioritisation and sprint planning.

B2B

For B2B the user and buyer are often different and the product positioning and messaging for both needs to good. At times the value of the product to the buyer adversely affects the current potential user base as it is bringing in efficiencies and change that the existing organisation would resist. User Experience is still important. I believe that when prioritising feature requests from customers and deciding what to build, product managers should ensure that what they build provides a positive ROI for the customer’s business, rather than simply building what customers say they want. The product team needs to have framework that allows a balance of user feedback and what is good for their customer as well as your own business.

Relationship Sales Team

Often in B2C, there isn’t a large direct sales team.

An enterprise sales team spends all day talking to customers — they should know the customer perspective inside out, which can be hugely helpful to a product manager. Success in B2B product management is nearly impossible without a good relationship with sales throughout the product lifecycle. But when sales returns to the office with a new client and a list of contractual features to implement, they become the ones leading product development — not the product managers. This can result in a backlog so congested and long that teams struggle to keep up and satisfy requirements quarter after quarter.

To avoid this, I think product managers need to think about sales as another customer

Practical approach for building a roadmap pipeline

The Vision / North Star is the guiding direction of where the product should be progress, which translate into Product Objectives and Key Results. An overall Strategy along if needed a Value Creation Plan if the audience needs to be clear and educated on the value that each product provides towards the North Star.

Practical Guide

Introduce these 3 routines to stay aligned

1.    Weekly triage: If you don’t do this, the whole roadmap approach will fail.

Set up a weekly triage meeting or block time to do the initial opportunity assessment of the new request and update other tickets if necessary. If you don’t do this, the roadmap pipeline will be outdated, and everyone will stop working with it. Start by building a habit for yourself and add people over time. These can be parts of the scrum team, the whole scrum team, or a key stakeholder (e.g. Marketing Manager for Growth teams). Find out what works best for your organization.

2.    Roadmap alignment: To leverage collective intelligence and maintain a focus on outcomes

I recommend meeting every two to three weeks. Invite key people of the team(s) (PMs, Design Lead, Tech Lead), your department lead (VP Product, CTO or their like) and maybe some key stakeholders.

Product managers must lead and prepare the meeting (not the VP Product or CPO, but PMs who run tribes and/or squads). This is the most important product meeting to connect operational doing with strategy. It is also the hardest meeting to run for PMs. You want to avoid being overconfident and defensive, but you also don’t want to be full of uncertainty and not have an opinion. PMs should act as facilitators of the roadmap discussion. This is how I suggest structuring it.

Start with a short update on the status of the OKRs of the team(s). My favourite question at this point is, “From 0–100%, how likely do you see your team achieving OKR X by the end of the quarter?”

Do a short update on what has changed around opportunities that are in [Discovery] and [Delivery]. If you are well-prepared, you will be able to share a short statement about each of the items to have everyone on one page. This is what you might say:

** Opportunity A has been successfully delivered, and I will share with you the initial results of the release via Slack later today.

** Opportunity B is blocked for a few days by a technical issue. Max is confident to resolve it soon, in the event we need further help we will let you know.

** Opportunity C got kicked off. I have shared a short summary on the scope for version 1 over Slack early this week. We will focus on it in the next 2 sprints.

** Opportunity D, the discovery is completed, and we decided to build an MVP to validate this solution on a next level. I will attach a summary of the findings in the follow-up of this meeting.

** Opportunity E, the discovery came with many unexpected learnings, and we concluded that we should not spend more time on this topic in the next 6 months. I will also share the summary with you.

** Opportunity F, we’ll kick off a discovery on this later this week. Let me know if any of you want to be involved in the planning session.

Share an update on the most important new requests and how you have assigned them on the board.

Mention other essential changes, such as, we prioritized Opportunity G from [Later] on top of [Next].

Let everyone know what questions you would like to get their input on.

Let everyone ask questions and challenge you.

Focus on prioritization discussions and avoid going into details.

The focus of this meeting should always be around the question “What opportunities/bets should we prioritize next, to have the best chance to achieve our OKRs”. Focus the discussion around this question. Push all other, more detailed discussions into smaller follow-up meetings and asynchronous communication. You can let people ask questions and have short discussions while you do your update (step 1. to 4.), but always ask them “Is this question/discussion helpful to make a better decision on our priorities or can we have it later?”.

If some stakeholders seem to have problems listening and always drift off in detailed discussions (particularly CEOs), then only allow clarification questions on the things you say during step 1.-4. Tell them to write down all other questions and address them in step 6. I usually guide them directly through the Kanban board. If you feel that it is too much information to process for them, you can screenshot each column of the Kanban board and put each on a single slide of a presentation.

Plan for 45 to 90 minutes

In a smaller group (4–6 people) who have done this meeting several times, you should be able to go through it in 45 minutes or even less. For larger groups and in particular groups who only recently started the practice, I would rather plan for 60 to 90 minutes. However, the quality and time depends on the preparation of the PM and the way the PM runs this meeting.

3. Synchronize your roadmap with the latest Objectives

After you have kicked off a new quarter and defined OKRs for the new quarter, you need to reflect the updated OKRs in your pipeline. This might mean changing some priority scores or reviewing the [Later] and [Not…] column for opportunities that might be worth considering, given the changes. I recommend blocking 1–3 hours at the beginning of the quarter for this routine, depending on the size of the group and how much your objectives changed compared to the previous quarter.

Relationship to Backlog and Sprint Planning

Often for the Now part and some of Next it should be reflected in Sprint Plan for the Quarter. Of course, Sprint Plans need to be adaptable but it does give a level certainty to the developers and if the roadmap communicated the outcome vs the output a cross-functional team will understand what the commercial purpose is. Below is some examples of what the scrum team should be focused on translated to features and tasks in the Sprint Plan.

Components of an Agile Roadmap

• Vision: The ultimate product goal, the North Star.
• Business Intents: Focus areas that lead to achieving a better product.
• Product Initiatives: Features that are tied to business intents. This gives an immediate sense of intentionality to all the proposed initiatives. If it doesn’t serve a business intent, why are we building it?
• Broad Timeframe: Instead of pinpointing when features are done, we simply say what we intend to work on now, next, and later. This gives us the flexibility of what’s most important, even when things change.