When I started to work in 1977, we didn't have testers. I wrote tests for my code, code reviewed with other people, and—every so often—tested other developers' code.
We missed lots of errors, both in logic and functionality. That led to a ton of product and project risks. (Yes, plenty of late and unplanned feedback loops as in the image above.)
However, we all had strategic and tactical product-focused skills in the form of solution-space and domain-space expertise. We understood the strategy behind the product and what the customers wanted, and we understood how to develop it. Sure, that varied from developer to developer, but we all had enough, and we had each other.
Fast-forward to 1985, about the time managers realized developer-only testing was not sufficient and formed test teams. I joined a test team then.
Since I was a developer by training, I wrote code to test the product. Because I could read code, I quickly learned the solution-space expertise I needed. That allowed me to ask strategic and tactical questions of the developers and managers. However, too many of my test colleagues had only problem-space expertise. They could not ask the same questions.
They were at a disadvantage.
Disadvantages of Only Problem-Space Expertise
My managers loved to say that the testers could read the documentation. But especially in fast-paced development, the documentation was never up to date. The problem-space testers could not easily increase their knowledge. And since they could not read the code, they couldn't use the code to learn.
Problem-space expertise does help people decide how to test. If you know the problems the product is supposed to solve, you can test for those problems. However, it's possible to miss all the strategic issues behind what you can see in the product. These testers had several disadvantages:
- An inability to discuss the design or architectural tradeoffs at the strategic project or product level.
- Lack of understanding of the various implementation tradeoffs. What did it mean when specific tests failed? Worse, how could the testers know if they repeated the same test several times or tested different parts of the project? Those questions have both strategic and tactical implications.
- Because their testing was limited to manual tests, they could not fully explore the product as necessary. That limited their testing to tactics, not strategy. (Some of these smart people did not know what to ask the developers for, to make more strategic tests.)
If testers can only test manually, they miss too many possibilities to find errors and expose risks. As a result, we had too many second-class testers.
20 years later, and things have changed for testers. Especially with agile approaches and a wish to decrease cycle time, we can't afford strictly manual testing. More testers have more capabilities, that allow them to think more strategically, not just tactically. That benefits the project and the product in many ways.
I'm seeing a similar need for this kind of evolution with product people.
Product People Need Both Strategic and Tactical Thinking
I used to think product leaders only required solution-space expertise. I was wrong. Product leaders—at all levels—need both strategic and tactical thinking. Not just for the product, but for the customers, and how to make the tactical decisions about what to include and when in the product.
That requires both problem-space and solution-space expertise.
When product leaders think strategically, they think about the product from strategy through tactics:
- Product strategy is the set of unique problems you want to solve for your ideal users. The backlog and roadmaps are tactics to implement a product strategy. Especially if you decide what to do never.
- They might need to consider the product marketing and or product distribution strategy, which is how you find those ideal users and help them buy/use the product. That affects the backlog and the roadmap.
- Which feature(s) would give us the biggest bang for our development bucks right now? Maybe just a little later? That might create a strategic advantage.
- Do we care about how the development team will implement this? Sometimes we do, because the choices they make now might prevent future choices. That's why I prefer experiments and spikes to see how to implement.
If you only have problem-space expertise, you can't understand why the developers want to do feature C, B, and then A, instead of A, B, and then C. Or why things take “so long.” Those conversations also require solution-space expertise.
But, I see too many organizations try to keep all the strategy in the “product manager” role and all the tactics in the “product owner” or “business analyst” roles. That's a false choice and short-sighted. A team needs sufficient access to both strategy and tactics.
Product People Can Evolve as Testers Did
Just as the testing evolution took a long time, many testers evolved to use both strategic and tactical thinking. Some testers prefer one over the other—and that's fine. As long as the team has access to enough testers who can think both through the solution space and the problem space.
It's the same idea with product people.
Too many teams share a product manager with strategic responsibility for several other products. Or they share a product owner who supposedly supports many other teams. These multitasking people are supposed to share their strategic vision and access to customers with the rest of the organization. Their organization chooses to “backfill” (their word, not mine) with business analysts. IME, great business analysts also think strategically and tactically, so the title does not help people understand the levels at which they need to work.
That creates bottlenecks and leads to very long feedback loops.
The more agility we want, the more everyone needs both solution-space and problem-space thinking. Teams need everyone to think strategically and tactically to create the best products as fast as possible. That's how we can create products that meet the customers' needs. We can avoid unplanned feedback loops and bloatware.
If you're one of those product people and your bosses have drawn rigid lines around the value you offer, start to rethink. Integrate your strategic and tactical skills and decide where you want to go.