“What” and “How”: The Theory of Everything

“What” and “How”: The Theory of Everything

Product nerds are in a unique position. We follow the lifecycle of an idea all the way from inception to delivery, and if we get a moment to breathe—a moment to step back and look at every step of this process at once—we’re liable to have a moment of distinct, terrifying clarity.

OKRs. KPIs. KRAs. Story mapping. Sprint goals. User stories and acceptance criteria. Aside from the variations in scale or the specific packaging they come with, they are remarkably similar to each other. What is a company mission if not a giant user story with various strategy components as its massive acceptance criteria? What is a sprint goal but a short-term objective with the stories therein as short-term key results?

When all the different titles and terms burn away we’re left with the same basic concept over and over again: The concept of What and How.

More specifically, there are two questions we must answer every time we attempt to move down one level in granularity, whether from an objective to key results, or from a user story to acceptance criteria:

  1. What are we trying to do?
  2. How are we going to do it?*

That’s it.

Usually your answer to #2 is a list of things. Start with the first item in the list, and make it the answer to question number #1. It’s now your What. Move, again, to question #2: How are you going to do that thing?

Rinse and repeat until your list of Hows is specific enough for a dev team to go build it.

It’s that simple. Or at least, it can be. But we have to be willing to resist our inclination to seek a tailor-made solution to every new project we start or problem we face. That’s why adopting these specific frameworks feels so good. If we’ve struggled in the past with breaking down big initiatives, or tracking progress meaningfully, then it’s so tempting to adopt a “new” method—which probably has several blog posts written about what makes it uniquely effective—and expect it to eliminate some of those struggles.

I’m not suggesting that we ditch all the frameworks I’ve mentioned. And I’m definitely not suggesting we add this idea of “What and How” to the list as a new one. Instead, I think acknowledging that they are all built on top of that same structure can actually help us use them effectively.

There are two major benefits to understanding this Theory of Everything:

First, it helps us communicate and collaborate at scale.

If we’re used to operating on a user story level but find ourselves in a conversation about business objectives, identifying the What/How structure can help us get our bearings and contribute meaningfully. Our knowledge is transferrable—the same formula that makes for good user stories (e.g. “As a… I want to… so that…”) works for crafting valuable objectives as well.

I saw this in action when my organization introduced OKRs. When involving the dev team in writing key results for our objective, this unfamiliar framework became a lot less mysterious when we compared it to user stories and acceptance criteria, with which the team was already comfortable. Objective = big user story (What). Key Results = big acceptance criteria (How).

On the other hand, if we’re more familiar with the domain of business objectives and strategies, understanding that dev teams work in tighter, faster cycles of the same structure can make the whole development process less of a black box. We should endeavor to speak the same language with one another at every level of the business without getting tangled in different words for the same concept.

Second, it helps us to set realistic expectations for implementing our framework of choice.

Once we demystify all the different planning and goal-setting tools we have to choose from, understanding that they all inherit from What and How, we can stop thinking of them as cure-alls for whatever organizational challenge ails us. If KPIs aren’t working for you, OKRs are not going to be a silver bullet.

Implementing a new strategic planning framework after we’ve struggled to write good objectives or define success metrics feels like progress. Putting the cart before the horse feels like progress, too, if we consider that the cart started out behind the horse. But this is short-sighted for obvious reasons. It’s not meaningful or sustainable progress, and in retrospect it’s a really confusing move.

A user story by any other name never did smell like much of anything.

Shakespeare, probably

The bottom line is, if we’re trying to break a big problem into smaller problems, thinking in terms of What and How isn’t merely a recommendation or a best practice, it’s an inevitability. It doesn’t matter what we call it, or how big-picture we’re thinking.

It wouldn’t be a very good Theory of Everything, otherwise.

*There’s a small caveat here that this question might, at times, be more accurately phrased “How will we know whether we’ve done it?” Which version you ask depends on whether you’re trying to come up with a list of steps/tasks or a list of success metrics. However, I think you could also generate success metrics by asking “How are we going to do it ?”,Holy punctuation, Batman! so for the purposes of this post I’m using it to mean both/either. Back

This Post Has One Comment

  1. Thomas Mirc

    A key consideration here is the financial performance of a product. Often OKRs and KRAs can be perceived by an uninformed executive team as a product team trying to justify underperforming products or over budget product teams. A high growth, or strong performing later stage product will often avoid detailed scrutiny, whereas new or poor performing products will be asked to “run the gauntlet” of exec performance metrics to justify their existence. The overlap of financial or portfolio product management and product ownership needs to be considered as a dimension of risk or an additional consideration in the evaluative process.

Leave a Reply