Previously I talked about project management and a quality focus. Here I want to take both down a level to get a little more practical, specifically around the idea of how that quality focus strongly encourages delivery teams to create product maps. It’s those product maps that will give a team the first insights into what quality is going to look like.
This notion or product mapping is where I think product management (and thus product mangers) and product development (and thus product developers) start to to intersect.
Since there are many very specific ways to craft a product map in a given tool — including using no tool at all! — I’m going to remain largely agnostic of tool concerns here and instead just focus on the idea of product mapping as a technique. The product map, as an artifact, is of course also important.
So what is this “product map” thing? Well, the product map is generally a high-level visual summary that maps out the vision and direction of your product over time. The goal here is to convey the strategic direction for the product and tie the product direction back to the strategy for the company as a whole.
Crucially, it’s important to note that a product map is not one over-arching view of the entire product. In fact, there will likely be multiple product maps. Specifically, and I think this is a good way to frame it, you will have one product map per market promise.
Let’s talk about what this means with an example.
A Mapping Context
Let’s say we’re a company like Steam, a site and platform near and dear to many gamers. As already stated, we might have multiple product maps as such: Product Map: Buy Games, Earn Points
Notice with that last example that we actually seem to talk about a lot of different things. And that can get us into trouble.
Well, trouble if those concepts aren’t related or aren’t part of a promise we are trying to deliver.
And that takes us back to that phrase of market promise. Sometimes you’ll hear this phrased as a product promise but I like “market promise” a bit better because it allows you to frame away from the product and more on solutions that a given market can or will accept.
To provide that promise, your delivery team will likely work in the context of some business processes. And I should note the latter term is very much used for lack of a better term. It’s just something that your business does to deliver on a promise. The most obvious example of this might be the Software Development LifeCycle (SDLC) that’s followed.
First let’s consider things a little generically and then a bit more specifically.
Promises and Processes: Generic View
Generically speaking, a product map is predicated upon the idea of a promise to the market. We can use the term market promise as a way to make a statement of capabilities or value that we would like to be able to provide to our market. That market, of course, being made up of our customers and users. In the case of Steam, customers might refer more to the game makers who publish a game on the platform while users will refer to the gamers who purchase and play those games.
These promises should be planned and deployed as an initial realization of the promise (think: “Release 1″ as opposed to “Version 1″) and then maintained and improved through iteration. As I said in my previous post:
It’s not so much about “Release version 2.1.13 out to our users” as it is about “Release these features that provide these outcomes to our users.”
So this gives us a nice concise way to frame and define the concept being discussed.
- Any individual product map is a map of how a delivery team delivers on a single market promise.
That’s pretty simple. But I also mentioned a business process. What is that? Well, we can start by tying the to the above definition.
- Any individual product map frames potential features and needs in the context of a complete business process allowing proper prioritization.
This context is crucial to understand. Your business success and value to your customers and users is measured based on the outcomes of the business process as a whole. Okay, great, but what is that process?
Well, unlike a technical, a business process is predicated upon realization that features are valuable only in terms of their impact on the ability to achieve those outcomes. You can work in a business and a team that’s a veritable feature factory. But that really doesn’t count for much if what your features deliver as outcomes is not something the market responds to.
So that’s the distinction. We can achieve some technical end result but is that technical end result something we can frame as part of a given business process? I’m willing to bet that this is still not clear so I’m going to frame this around an example in the next section.
For now just stick with me and let’s agree that a product map is a primarily visual summary that helps translate a business process into a set of prioritized Features which create a complete user flow and outline how that flow can be refined and iterated upon.
Promises and Processes: Specific View
So now let’s get a little more specific. An example of a market promise for Steam might be something like this: “Enable gamers to discover various options around available games to facilitate more spur-of-the-moment purchases.”
There’s a key qualifier there, though, and it’s one that isn’t stated. Steam likely wants to facilitate purchases that the user will be happy with. If people return most of the games they bought, the overall experience would likely be one of them questioning how much they should bother trusting, say, the recommendation system. So, again, just delivering on a promise (a way to discover games) is useless if the outcome does not provide value.
And this takes us into the concept of a business process because that gets into what we will do to provide that value. Note: not how we will do it; just what we will do. Thus the business process associated with a market promise is the set of steps or tasks the delivery teams go through in order to achieve the promise of value that is ultimately being banked on for some measure of success.
Here’s how we might visualize that on our product map for our Steam example:
Here the business processes are the green and blue boxes. This is what the team feels must be done to realize the value of the market promise; this is ultimately what allows the market to receive and realize the value we claim we’re providing.
And, I would argue, tis is certainly giving us some insights into what we believe quality will look like. If you look at that visual, notice that it’s a bit of a spectrum of quality, right? By that I mean we can imagine various quality measures for each of those elements. Also note that it’s possible to work on one aspect of the promise without having to work on all.
So think of the business process as a series of activities that must be done in order for us to go from idea to deployment of the idea in way that customers and users can achieve value from. But notice that none of those boxes, by themselves, could or should become the basis for work in terms of user stories or tickets in our tracking system. This product map is really just doing that: providing a map of insights into what delivery of quality might mean. It’s providing a structure for us to consider our ideas but without getting bogged down in implementation details about those ideas.
We can start to break that initial visual down a bit further. Consider the following:
So now we show how the promises from the previous visual are broken down more into the start of processes. We also state what we think the core problem is — purchase discovery is not intuitive enough — and that means every business process on this part of the map should be speaking to that problem.
Here “ED” refers to an Engine Developer on our delivery team while “CD” refers to a Content Designer. And what this is showing you is who, among the delivery team, is most likely to deliver on the promise. In fact, the last item in that visual — the “create game streaming schedule” — has the little circular bit at the top right and that refers to the audience (content designer) that the particular business process is targeted to or for.
Now you might think, “Well, wait a minute here. Shouldn’t the process be targeted at the user or the customer?”
But keep in mind the business processes are targeted internally. They guide the work of the delivery team. The customer or user doesn’t necessarily care about how the delivery team creates a schedule. They may not even care what that schedule is. But they do presumably care about how they can see games being streamed.
Yet how they can see games being streamed is implementation; we’re not talking about that here. We’re talking about intent. We’re talking about what promises we want to fulfill and the processes we believe will fulfill them because those processes are tied to the promise which is in turn tied to a problem (“not intuitive enough”).
Notice how implementation details can creep in, however. You might have noticed the bit about the “GAMEHL format”. You could argue that this is providing an implementation detail. And, to be sure, it is; but it’s probably one that’s worth keeping in mind. If we’ve invested a ton of effort in a standard format for how our game information is stored and made available to customers and users, it’s probably likely we want to make it clear than an internal promise is we’re not abandoning that. Thus our business processes should keep that context in mind.
Epics / High-Level Features
How all this breaks down further is that our product map will be composed of epics and high-level features.
Crucially, how I like to frame this, is that epics will become tickets in our tracking system of choice; high-level features may become tickets.
I say “may” because, at this point, we are not focusing on whether the user story that might result from all can fit into a sprint. And whether a story can fit into a sprint of work is the definition of a feature when tied to a user story. It’s how we scope our work such that we feel confident we can deliver it, with acceptable levels of quality and within an acceptable time frame.
Also note that this approach allows us to avoid the complexities of “initiatives” and “themes” — which a lot of tooling, like Jira throw at you — and thus this gives us flexibility to morph our product map as we choose.
Ultimately, however, everything we are going to work on becomes a feature. This maps well with the idea of moving from discovery to elaboration.
As we start moving down that path, our process statements can get a little more prescriptive rather than descriptive.
Above is an example of how we frame some high-level thinking and strategy around particular teams, such as Engine Developers, and the audience that these strategies may be targeted to, such as Content Designers. The green boxes in this context are business process activities while the blue boxes are high-level Features. In fact, we can break this down a little further:
Above is an example of how the overall purchase discovery strategy is conceived of with an epic and that epic is broken down into high-level features (the green boxes). We’ve annotated with our design goals (“make less painful”, “make more intuitive”) and we’ve indicated that an internal quality (“Design”) should be incremented as a result of this.
We’re very close to the idea of the user story here. And that means this is probably a good time to stop because user stories and the flow of them is something I’ll talk about in the next post on this topic.
Quality Insights
Before I close out this post, I want to make sure it’s clear how quality insights fit into this. First of all, notice that since we’re not throwing everything into tickets quite yet, it’s very easy to move the visuals around and create our own framing narrative about our product and the market promise we are trying to deliver on.
Along the way we learned that we are concerned about a few things but the core one is that the purchase discovery options for our users might be lacking. We believe that we can make that discovery process better. But to even worry about this promise, we actually have to have something to discover in the first place! Maybe it’s focusing on special sales we’ll have. Or we’ll focus on what seem to be trending games (even if they aren’t best sellers). Or perhaps we’ll focus on what the community of gamers recommend as distinct from what professional review sources (like GameSpot or GameInformer) recommend.
All of that may make us realize that to deliver on these aspects, we have to decide when special sales will take place. Is it just summer and winter sales? Is it specific holiday sales? Can there be random “just because we want to” sales? If we’re going rely on game streaming, that too has to be scheduled. You need someone who will actually stream the game (and ideally perhaps an influencer) and an audience to watch it. This suggests not having streaming schedules mid-day during the week, perhaps, when a lot of people are at work.
Certainly you can see some quality insights emerging there.
We Are Doing Testing Here
This is where quality assurance, as opposed to “just” testing, has the best chance of happening. We are, in fact, testing at this point. We are at one of the earliest times when we are likely to make mistakes, which is making assumptions about what it makes sense to do in the first place. Thus we are testing our assumptions and our understandings about our market before we start delegating work to do.
This, of all times, is when we have one of our best chances to do something as unlikely as actually “assuring” quality. As the saying has it, the worst waste of time is time spent doing something really well that need not be done at all.
I’ll also note that if you look at the above visuals in order, from top down, you see that we start to refine what our product map is actually going to look like. And, again, keep in mind, it doesn’t have to be just one product map. You will probably have multiple. And you might even move between them with your delivery teams. It might even be the case that work on one product map removes the need for another.
I do believe a key point to all of this is that at every step, we gain further insights into what quality means for us.
We don’t, by any means, have a definition of done at this point. But we do (or should) end up at a spot where we could start getting into the actual work that we’ll do. And that will take us from quality insights into quality understanding. That will be where I pick up the next post as I tie that understanding into the artifacts that developers and testers use to realize the vision of the product map.
