Product developers know about the “Why Stack” and it’s important that developers and testers are able to work in this context. So let’s talk about this a bit … although I should note I’m going to refine a little bit about how the “Why Stack” is considered, moving it a bit more into where it intersects with how we think about features that we want to develop and test.

While this post is situated within my product development category, the title shows you that I’m actually focusing on the delivery team as a whole and that’s where testers, in particular, should be aware of how and to what extent the “Why Stack” works to help us understand elaboration. Elaboration is what gets us to our features. Features are what we specify. And if we specify something, we absolutely want to test that which we specified.

Popping the Stack

In general you’ll hear about how you should “pop the why stack”, usually at least five or so times. What this basically means is asking the question “why” recursively until you end up with some aspect of the following business values:

• increasing revenue
• protecting revenue
• reducing costs

Those are what I talked about in relation to “hunting the value” in my post on product development injections. I also added another business value to that list:

• maintaining or enhancing competitive advantage

The idea here being that if you’re about to implement a feature that doesn’t support one of those values, the chances might be good that you’re about to implement a non-valuable feature.

However, I don’t think you necessarily have to do this around asking “why” recursively. Rather I’ve had much more success simply using “why” as the starting point, and then focusing on the other aspects that might inform the why. This is how, in fact, I find delivery teams can more quickly move along the spectrum of discovery to ideation to elaboration.

Feature Mappings

A mapping from “what we want” to “how it delivers value” requires conversation around four types of questions: Why? Who? How? What? I think so much emphasis gets put on the “why” (and thus a “why stack”) is because what often got left off was the “why” in the first place. In fact, as most product developers will tell you, what gets left off of feature injections is often the “why” part of it. In case you aren’t aware of the feature injection format, it goes like this:

• As a who …
• I want what …
• So that why.

It’s the last part of that which often gets left off.

And, to be sure, when that happens, the other aspects in the chain can suffer. One of the goals of a spec workshop is to make sure that this doesn’t happen by making sure the “why stack” is understood. But I also think this understanding entails rethinking the need for a “stack” necessarily.

Working from Business Outcomes Forward

One way to do this is to start from the goal or the final outcome expected for the business. Then you use this to drill down to the who, the how, and the what.

You start with the business goal you want to achieve. So let’s take this from the point of view of a company like Valve that runs the Steam gaming library service.

Now, notice what I did there. I stated something quite important to the business. But not so much to the customer base. Gamers using Steam aren’t out there desperately hoping that Valve’s revenues will increase by 20%. So this is not immediately from the standpoint of a customer and, for some product developers, that’s practically heresy.

However, notice this: as part of investigating that “Why are we doing this” statement, you will look at who will benefit from, or who can help achieve, the business goal. That includes anyone who might be in a position to prevent this goal from happening or make the goal harder to achieve due to some realities or logistics. And, ultimately, that means this will be framed in terms of the customer because, after all, it is via customers that the revenue will ultimately come.

Okay, so let’s look at the Who for a moment:

So we can consider these are stakeholders but, even more accurately, I would say these are the personae that we want to consider. Each persona is one that we could consider injecting into our features and into our scenarios that demonstrate those features.

Then, with that in place, we can start asking how these stakeholders can help achieve these goals.

Notice how “buy more games” ties in well with “frequent game buyers.” What we’re really saying is we want them to “buy more games even more frequently.” And not just that but we want to get those frequent buyers or games to encourage others to do so. But we also have those who are selling games, such as the independent game developers.

With this in place, you start asking what you can you do to encourage or allow the stakeholders to modify their behavior to help achieve the business goal. Here “modify their behavior” can simply you provide a new feature that you encourage them to use in a certain way. But here’s where you really start to get into elaboration. So let’s leave that a bit unfilled out for now:

Putting some common sense names to these areas, you end up with this:

This is why I say you end up at elaboration because you end up at the features that support the business outcomes. Each feature speaks to a specific capability that is required for certain kinds of stakeholders so that a very defined business goal can be achieved because the stakeholders are encouraged to exhibit a certain kind of behavior.

I want to talk about these features a bit, but notice here we moved from outcomes to features. Can you go the other way?

Working from Features Backward

You can and I think a lot of places do. But I’m not sure that’s the most effective.

You could, of course, do the above in the reverse order. You could start with the “What” and work back toward the business goal. Of course, any product owner will tell you that this is a bit of a backward way to do things. It’s what tends to lead to the most project churn, the most misaligned features, and the most bugs.

If you find your delivery team is delivering the “wrong features” or not enough of the “right features” or you feel like you end up with a lot more misunderstood requirements and bugs than you feel you should, you are probably taking the “feature factory” approach and doing the above backwards: going from features and trying to derive business goals after the fact.

Elaborating the What

So while the “Why Stack” is important conceptually, what I’ve kind of shown here is that I actually don’t think it should be much of a stack. Consider what we started with:

• Why are we doing this?
• To increase game sale revenue by 20%.

Obviously popping this stack recursively may not be as useful. They want to make money. That’s clear. I mean, yes, we could have started like this:

• We need to offer more games on our platform.
• Why?
• So we have more games to sell.
• Why?
• So … that we can sell more games? Are you not getting it?
• Why?
• Games makes us money. So we want to sell more games. Seriously? Are you not getting it?

Now, obviously, this can lead us down the path of which games make more money. For example, should we focus on first-person shooters? Adventures? Large-scale RPGs? But that’s getting into the other areas beyond the “why.” Also notice how this conversation might have differed if we started with: “I want to attract more people to the Steam platform given that we are now dealing with other competitors like the Origin Store and the Epix Store.”

My only point being you can generally get to the “why” pretty quick if you know how to ask the right questions fairly quickly.

So we left the “what” (the features) off the diagram. What might those look like? How about this:

• Frequent game buyers
• early access releases
• targeted wishlist sales
• social media integration

• Indie developers
• ease of deployment
• early access
• game-casts

Notice here that we quickly get to some aspects that can be elaborated. What does “ease of deployment” mean? How does that actually manifest for an independent developer? What does “early access” even mean? And for our game buyers, it sounds like we have an alignment around “early access releases” and “early access” for our indie developers. And what social media do we want to integrate with? And would the game-casts be deployed on our (Steam) platform or on that social media?

These aren’t asking “Why” questions; these are asking “What” questions. And, ultimately, if you want sustainable development, you much more need to be “popping the what stack” than the “why stack.”

My experience is that this gets you much more quickly to thinking about what successful interactions with features looks like which gets you much more quickly thinking about acceptance testing. And acceptance testing is very much a core intersection between product development and engineering. It is an intersection that is mediated by testing (as an activity) and possibly tests (as an artifact).

That’s what I’ll be talking about in the next post in this series.