The Platform as Product "State of the Union" Exercise

One of the risks of "longer term" projects which a platform can potentially be considered is it starts but never feels done.

A simple framework is to set a beginning middle and end state for the platform.

I realize that, if done well, the platform is never truly done. After all, one of the tenets of the Platform as Product Mindset is: "The Product is Always Evolving"

However, a good way to get a handle clarity and excitement of the product is for the Product Manager to hold a State of the Union.

This should be done within a 30-60 day timeframe from start.

What is the State of the Union?

This is a date in which all stakeholders, participants, and users will attend a concise presentation on the state of the platform.

Especially when trhe work is nascent, having a crisp kick off can help. It puts greater accountability on the team to deliver. But at the same time can ensure that blockers or resources are also addressed way ahead of time.

However, in order to succeed, you have to work backwards.

Present the template to executives

First, use a high level template such as this one as a deck for executives.

This will be mostly content free when you show them.

But you want to set the date in the sand.

Here's what you want to cover:

Who will be interviewed?

If you can anticipate the key stakeholders (use my table Stakeholder Maps for Platform as a guide), fill it out with names, titles, dates/status.

Set out a set of dates that is reasonable to interview them all. Use good judgment based on your own availability and the cycle.

Then make sure that the key executive or executives reviews this and agrees the people are on it who need to be AND no one who is key is missing.

Spend time on this. This is NOT to survey the entire engineering team. You want to ensure that voices -- the detractors, resistors, champions, or outliers -- are included directly or by proxy.

Include the key, relevant executives themselves.

They need to demonstrate leadership by participating.

When you do this, explore or validate whether the platform impacts valuation or other strategic value.

Generating and constraining the list

Take a first pass yourself, ideally with someone who is in the Engineering department who knows all the players and has an interest in the project.

This can be a friendly VP of Engineering. It can be an individual contributor who has been there for a very long time.

You can begin to seed it yourself by getting a copy of the org chart and thinking through the big buckets of services that the engineering team is building. This can be a good way to not only understand groups of the internal developers, but also a way to think about possible primitives for the platform itself.

Interviewees you should include for valuable perspective:

Then, after you have done so, list the date it was completed on the tab.

Include in the list the start and planned completion time for the interviews. After each update with a new interviewee, note the updated list.

How to get the interviews going

Once you have this blessed by at least one key executive,

What you will summarize?

Here's one way to do it. I filled in a few so it doesn't look blank, but obviously you would want this filled out.

The categories are up to you as well.

Current

You want to capture the primary pains and then bucket them. Now for the template you won't know what those are necessarily.

However, the interview template has areas to help jog your memory conversation.

We cover the five components of infrastructure. You want to make sure you get their perspective on each one.

Then in the areas of pain, we have big buckets: Cognitive Load, Wait Times, and Friction.

I think these may change based on your situation. But I used these three as sufficiently large and common-place to explore.

The art of the interview though will be digging deeper than those elements to get real actionable coloring.

Initiatives

A chunk of your time will be spent thinking through a clear plan to prioritize and tackle the various problems you uncover.

This is the "means" to your ends.

My starting point for how you may want to consider the initiatives are: Self Service Flows, Requirements Convergence, and Documentation.

Why?

Self Service Flows

I think an initiative that targets the workloads or workflows that are low-hanging fruit to make simpler, more efficient, or better standardized makes things clear. This could be something very simple and basic.

For example, it could be getting a developer to be able to ship a "hello world" onto a compute cluster, complete with DNS, logging, and autoscaling (dunno, just making it up.)

Something small. I think approaching things from how a new developer gets going can be a potentially meaningful win if it's small enough to ship quickly.

Breakdown the flows if you need to for yourself, and then size and level up for this slide.

Converging Requirements

You may likely uncover lots of unresolved decisions and architectures. These should be surfaced as a question to be resolved, "A scalable data backend" or "A standardized KV store" or something where the decision still needs to be made on what and how you will address it.

The deliverable may very well be just requirements, but it's valuable to call out that it's an unresolved decision-point and the goal is requirements.

Documentation

I would pick strategic points of documentation, such as those with high cognitive load or things that typically go to ticketing that can be address with a well-documented SOP.

Things that have heavy documentation and massive SOPs are good "smells" for opportunities to abstract bits and pieces away.

But the act of documentation may, in fact, be a meaningful win. The documentation may be non-existent for all you know, and getting it clear is just the thing developers want and need!

This can also be a place for new processes, like working with InfoSec or Data and Privacy teams.

Value

You want to get feedback in terms of what the benefits would be. If you solve them what would people experience.

Make sure your notes are well organized to keep circling back with different stakeholders. But spending the time to understand these will make the difference.

I feel Value should cover the four I outlined: Strategic Impact, Customer Impact, Revenue Impact, and Cost Impact. Some other set may emerge, but I feel that these are good to use as part of your discovery.

Imagine you have to make a presentation to the board of directors to justify continuing with the initiative: what value really sticks and makes people care.

The cultural touch point you instill here is problem-solution-value. It anchoring the Platform as Product as the backbone from a current state of pain to a future of benefits.

This isn't aspirational. Its solution focused and this is an important cultural touch point.

How will you get the insights?

Here you will go back to the interviews. Remember: you want to make sure that you get lots of actual individual developers as part of your roster, not just management.

I propose using the following framework when interviewing developers 1:1.

For each category of the platform that you may be responsible for (if you are delivering the entire Platform, you are likely on the hook for the whole thing; but it's possible you only have responsibility for a single silo), talk with the developers using the above template:

When I try to A, I hate it because I have to B. I would be much more C if I could just D.

Ask questions to solicit answers in this framing. They may not respond in this way, but you want to sum it up.

Notice I use "hate" because I want to dig for the emotion underneath. That helps find what the underlying issue is. It should be about their pain.

The "D" is a consideration -- you will probably NOT build what they recommend, but you want to pull out in their words the "C" -- the benefit that they get and use D to uncover what the solution space could be.

They could be right if 90% of developers say the same thing, "If we could just all use Docker Compose." But more likely it's a good way to find the direction of what the initiative should be.

Illustrating Key Examples

To make things concrete, you'll want to highlight one or two examples that have alot of interest and that is chunkable into something you can make.

Ideally, this represents one of the key "golden paths" you want to introduce.

You can introduce one or two in this way:

If the slide is too complicated, then I would perhaps break down the full workload at a high level and chunk processes down and then pick one of the key components to get into more detail.

When you have too much visual complexity, it's often a tell that there might be too much complexity in the proposed workflow.

One of the goals and value adds of the product manager is to work with developers to reduce cognitive load and identify common areas of abstraction, templating, and automation.

Rallying Cry

You want to spend time to distill a clear rallying cry. This should at minimum convey the top-level umbrella benefit people will experience and buy into.

Do not make this too aspirational or vision. It needs some. But must be grounded in reality.

It is not the place to talk about the detailed end state.

It's about the Values that will be unleashed through the Platform. It's a Vision of how the business will run and the lives of engineers will be impacted.

This is a culture setting moment by driving values. It's where you want to keep steering the team whenever you can.

For Values, this may take lots of iteration, but it's also good to align with how people in the company get things done but also think about what makes you successful.

For example, I have been in environments where I was the first person to introduce bi-weekly demos. It was a new concept, but people were attracted to it.

It took time, however, to get our team on board and accustomed. But talking about values can help give the space to execute.

It should also include how you think conflict and collisions should be handled. Look to the culture but try to find something operational.

For myself, I found (from my experience in the Blockchain), that using the litmus "harmonize for ecology" meant that in the end, we had to go back to what is best for the ecosystem. This can get heady, but it's more meant to not do local optimizations and individual preferences, but try to answer the question of what is best for building a thriving ecosystem around a given public infrastructure.

Team and Milestones

This is project manager like. But unfortunately this comes with the territory at the high level.

How this instills culture, however, is continuing the thread of Ownership.

Many companies and individuals are used to blaming or hiding from accountability.

At the same time, many individuals who do contribute aren't used to being highlighted.

This does both.

However, you need to have credible major milestones and make sure everyone on the team signs off before this is presented publicly.

IF you assign people and they haven't had a chance to sign off, it's deadly.

However, at this point you will always want a link to an actual dashboard that you will update manually.

Week by week, you will use a green, yellow, red.

Initial Communication

The very first communication should be by the sponsoring executive. Ideally the CEO. The cc like should be you.

The email should go to the company, but address the people that have been specified in the "To Be Interviewed" list.

No one on that list should be surprised!

That's the job of the Product Manager to ensure that they are good with it and expect it.

That email should include something to the following: "Please work with X on this valuable initiative. We all want your feedback and participation."

Once that has been sent, you, as the Platform Product Manager, follow up.

One of the things to do is set up a Calendly link just for this interview series versus asking people to book time on your calendar.

This does a few things:

  1. Set a time limit on available slots. You need to schedule the interviews quickly
  2. Provide an immediate call to action
  3. Provide a link upon scheduling to a short video of you can of you describing the purpose of the meeting. About 3 minutes long max.

This starts the clock on your project to start meeting with people and thinking through a structure of how to present your findings.

What next?

The purpose of the State of the Union is to ensure people are aligned in terms of problems to solve, the goals/vision, some of the key workstreams by teams and outcomes.

This is just the beginning.

Now the important part which is ensuring you continue to deliver in an agile, responsive way.

This is more traditional "program management" side of product management, but it's important to deliver to increase credibility and momentum.