Aligning the organization with ProductBoard

I see three phases of product management: collecting input, processing information and input into a plan, and then aligning the entire organization on it. All stages are important, but IMO, the alignment phase is the most important one. This is where product managers drive cross-team organizational efficiencies and achieving results.

The question becomes, what does “alignment” entail? What are the components that make up alignment, and how can product managers introduce those to the entire organization efficiently and collaboratively? Let me take a swing at it. Here are the components of your alignment:

• Product Vision: What strategic value does your product offer? short and robust statement. Differentiated, clear value.
• Outcomes: What aspects of users and usage are we looking to optimize/accelerate in order to move the business forward?
• Product ‘swim lanes‘ and initiatives: there are many ways to carve your product into components (note, we’re not talking about features YET). Swim lanes could be considered in the following manner. Every product probably offers three aspects: the core offering; access- the user experience, UI, APIs, integrations etc.; and lastly, governance i.e., role based access, authentication, security standards, data retention, privacy policies etc. Components, or initiatives, are continuous, never ending investment. For example, investing in standard compliance (SOC2, ISO 27001, GDPR etc.) can be considered an initiative called “Standard compliance” and have point features over time.
• Features. Note that the features themselves, for the sake of this conversation, should NOT be about the code drop. Features and their details should represent the value to the user. I will offer later more detailed perspective how a template could drive the appropriate messaging and clarity around the value of the feature vs. its technical implementation.
• Focus: Another element of alignment and clarity, is the STORY that we want to tell on a regular basis. What’s a story? it’s why someone should use us. How do recent changes to the product offer a new perspective, use case, value etc. Stories give focus to both the delivery organization (product, dev, design etc.), as well as the rest of the organization (sales, presales, marketing etc.). Stories are best created in collaboration with product and product marketing. Stories should be created monthly, and in addition, per industry event (announcement, trade show etc.).

Let’s take an example. Let’s say that I am building a product that supports the notion of application quality, from the authoring of requirements all the way to production stability.

• Product vision: Control plane for heterogenous application quality

(What the heck does that mean?) Our problem statement is that we have multiple different types of applications (mobile, web, TV,..), developed in different languages and frameworks, for different devices (hence heterogenous), where quality needs to be tightly managed throughout the application lifecycle. ‘Control plane’ comes to say, across the highly rich and distributed nature of activities, data streams, assets etc., involved in continuous quality activities, a ‘control plane’ ingests and normalize signals, offers a dashboard of actionable insights, and offers the means to take actions (automated or manual) given those insights (like, rerun a test because it failed and we applied a fix).

• Outcomes: Increase the value for our users, as measured by the % of users expanding their test automation practice from x weekly users to Y.
• Product swim lanes and initiatives: core: Infrastructure, test automation, reporting etc.; Access: UI (portal), integrations (build servers, reporting systems etc.); Governance: Role-based access control (RBAC), SOC2 compliance, admin tools etc. Initiatives (let’s just take Governance for example): Admin tools and standard compliance
• Features: Let’s take just a few samples. Inside admin tools could be resource allocation per team, bulk addition of users; in standard compliance two examples could be SOC2 and let’s say FedRAMP. We’ll come back to feature details.
• Focus stories: Let’s say we’re in May and we want to craft a story focus for August and September. What are the key 2–3 events, or achievements that are important to announce and focus on for each event, or on a monthly basis? for example: Selenium Conference takes place late July, it is very interesting for developers and QA professionals. There are also key vendors and partners in this event. We should probably consider enhancing our core offering (test automation and reporting), as well as the access aspect (the UI and/or integrations) to have a good story, one that customers would love as well. Let’s tell that story and focus on it!

This article will split into two. Continue to read below to understand and see more how to articulate the above in a single view in ProductBoard. In the next article I’ll talk a bit about the mechanics, how to create this hierarchy and view.

How does all of this stitch together and why it matters?

How often you, as a product manager/product marketing manager ran product-sales enablement for the 10th time, only to realize sales don’t get the story. Ever asked yourself why is that? Here’s two potential reasons: 1- The story is not cohesive. It’s not tight enough to make sense. The strategic vision is telling one thing, and what sales is discussing is something completely different. Probably features. 2- If you have a cohesive story, it’s not available all the time for real time consumption. Remember, when you (the PM/PMM) are ready to tell your magnificent story, sales/presales/success/support are chasing the current lead or putting out the last fire. Information needs to be available and simple enough to be consumed offline.

How about a different approach? Vision through to features and focus, on one screen, with what matters. Available to anyone, at any time, on any device. Oh, and, no extra work.

(Pre sleeves-up) DISCLAIMER: when I was working on this, I was using ProductBoard (PB). It’s one of the leading product management tools, but not the only one. I do like it. But I am not a PB employee, not compensated by them, and maybe there’s ways to do the same thing in other tools.

What does the cake look like?

Vision, Roadmap, Focus, all in one place

Let’s break it down, from the perspective (intentionally), of someone other than a product manager.

What do you see?

The components of the feature view

Top left- the vision. Let’s always keep that in context. Oh right, “Control plane for heterogenous application quality”. Got it.

At the top I have good search and filter utility to find what I need, if my use case is looking for something.

The vertical columns are months. The progression is right-to-left, meaning, how are we progressing in time with our product.

The rows are split into two: Focus and the swim lanes.

Focus is split into two: Monthly focus: what are we doing each month and why, and Event driven focus: what events are interesting and what story we want to tell. Good news, everything is clickable, so a marketing/sales person can see that we want to focus on that Selenium conference. Here’s an example of the marketing event template:

The “marketing/sales” story

What a great place for product managers and product marketing to collaborate! (and, be ready in time).

Let’s give it a try, shall we?

• The story: We are coming to Selenium conference with breaking news about integrating test automation with Google Lighthouse for Chrome (lighthouse)
• 60 seconds elevator pitch (who cares and why): The lighthouse tool suite offers rich information about various aspects of the web page (performance, rendering, network etc.). For the same effort of authoring and maintaining a functional test script, a test can also produce other aspects of quality, for no further effort!
• Top 10 discovery questions: Are you getting consistent per page performance measurement and trending over time with your testing, how? Are you sensitive to network calls and how do you examine changes etc.
• Highlights (what will the product team deliver to make this reality, the ‘HOW’, features): Integration into lighthouse, embedding the results in the test reports, showing trends
• Outbound promotion: PMM will highlight this on the website, blog and whitepaper, there will be a talk in the conference with lighthouse developer from Google etc.

If I’m in sales, I’m meetings in Selenium conference to talk about this!

Here’s the template for the monthly focus, which might be more inbound for product and dev:

The monthly focus story is a little different. What are the outcomes we want to achieve, and how?

The “This month focus”

Next, down the rows, we have the swim lanes. You can customize this view and call them anything, but for me, the simplest way to think about this (as I wrote earlier) is core, governance, and access.

Inside of each swim lane we have initiatives. Those always continue to evolve, these are the pillars of the product. We talked earlier about test automation and reporting inside the “core” swim lane.

The swim lanes and initiatives

Lastly, you can expand or collapse the initiative to show the key features. Imagine here, I can see that, for the Selenium conference we are planning to add the lighthouse integration and the reporting that’s needed. Very cool, and aligned with what the marketing even focus detailed. VERY COOL.

Initiatives and features

Let’s take one step in. I am sales and I just so happen to be sitting with my presales, who, let’s say, is skeptical and wants to see the details. NO PROBLEM. Click on “lighthouse integration” and what do we see?

Feature detail

• Feature name: Google Lighthouse Integration
• Summary: Enabling testers to add lighthouse evaluations on each page in their test script
• Business value: Lighthouse offers valuable information about each page. Adding these evaluations is massively important, and if we can add those to test scripts that already run, with no effort, that is very interesting.
• Use cases: As a tester, I would allocate add the ability to my tests to run lighthouse scans on the pages in the test. I would like to see the results per page in the test report.
• Why: Because, as a tester or developer, I would know much earlier about performance, network, rendering and other possible defects I introduced while coding, before it goes to production.
• Competitive: We will be the first vendor to offer lighthouse integration. This is not a sustainable differentiator on its own (anyone can do this integration), it’s more about ensuring performance of the test and providing actionable insights from the findings.
• How to demo: As a tester, I take an existing script, I add a capability called “LightHouse” = true, and I run the test. When the test is complete, I can see that the test report includes lighthouse results for each page. I can also show that the test runtime did not increase more than 10%. (Screenshots advised)
• Future improvement: Provide trending for the scores and diff between test runs.
• Discovery questions: How are you getting performance information to your developer quickly?
• Assumptions: Test is run on Chrome
• Limitations: Initially, once the capability is turned on, all the pages will be scanned. The user cannot select individual pages in the script.
• Metrics of success (how do you know you delivered the value?): 5 users tried it in the first week from launch and grow 20% WoW in the next 4 weeks. The number of tests enabled per week is 50 and growing 20% WoW in the subsequent 4 weeks.

As you would expect, every feature also has a timeline, and more important, it has a link to the actual developer ticket tracking system, so you can learn the actual implementation etc.

OK, this is a good stopping point. Let’s wrap up. We went from the vision, to the components of the product, to the features. Anyone in the company can read this story at their leisure, and see the product progression.

Understanding the roadmap in context

Specifically, using this construct, It is possible to locate a feature in two dimensions:

• The horizontal dimension is the one we’re used to from every roadmap. This is the progression over time towards that vision.
• The vertical dimension shows how does this feature fit within this month focus, or towards a marketing event. This is a strong concept, since sales and marketing don’t want just a flow of 10 features, they want a story that breaks down into features, bundling.

I hope that in this (yes, long) article, I’ve shown how you can compact all of the critical planning and alignment information into one view. This forces us to be authentic with ourselves: The vision cannot be directed differently from the features and vice versa. There are time-based stories that tell our progression in context of the vision. And they are made of features, which are tied to real users. This is a really good way to tell a simple, robust and differentiated story and align the entire company.

In my next article, I will share some tips how to build this view in ProductBoard.