When “What vs How” is not enough
If you hang around product managers or developers long enough you are bound to hear the old saw about “what” vs “how” in requirements. It actually forms a pretty good basis for division of responsibilities and teamwork. But sometimes people get bogged down in the esoteric argument and miss the fact that some answers are in between.
What is “What vs. How” and how does it work?
So, first of all, let’s explain the what vs how model. The idea is that product management should focus on defining the intention – the ‘what’ – to build where development should be able to take that input and decide ‘how’ to build it best.
up the what.
This aligns well with the respective roles. The product manager is engaging with the customers and market and is responsible to determine what can be successfully sold to them. This makes
The developers are responsible for finding the most efficient, best way to implement this in the product or the how.
There is a motivational bonus to this organizational model: It clearly respects each members expertise. It leaves room for creativity on both sides while ensuring that expectations are communicated clearly.
It’s worth noting that neither product management nor development should do this in a vacuum. Product management is expected to share the what while it is still being defined to help assess the feasibility and other practical feedback. Development should be sharing technical designs and specifications before they are committed to code to ensure that the artifacts of design don’t conflict with the final, delivered what.
So where’s the problem?
Sometimes a debate arises over how much detail should exist in the definition of the what. When product managers start to put technical definitions into the requirements documents, developers (and others invested in the process) sometimes balk. They cry out in foul:
“But that’s a ‘how’ thing!”
It is a fair caution. Sometimes a product manager is actually overstepping the boundary. In this case, it is good to issue a reminder. Regardless, all should see it as an opportunity for a more rich conversation within the team about what is really needed not as a battle call.
But what about when that technical detail is actually part of the requirement for the customer?
What’s the answer?
It is possible for any product to have a feature where it is important to the product manager – representing the customer – to define the technical aspects of the product. This has long been the case with sub-component manufacturers for years, but now the software world sees it too with APIs and other products meant to be integrated into other systems.
Let’s take an example I ran into a few years back. We were building commerce APIs and wanted to provide a flexible entitlement API that would not only be the back end for the engine we were building for ourselves but also available for our customers to build their own systems. We wanted them to be able to leverage the same API even though their business rules might differ.
As such, it was important to think through other kinds of use cases. For example, what to do with a subscription that was not current at the moment the API was invoked. In other words, would a grace period be allowed or would the call be rejected?
For our system, it was ok to turn off a service to a customer quickly if they hadn’t paid. But for our customers, that might be a bad business practice. Perhaps for them, it was better to give free service for a month than to risk interrupting the service. Both are valid business practices. To build a ‘universal’ API, we had to ensure that it could support both use cases. As such, we needed to not just provide a yes/no flag for entitlement, we needed to add information to the response about when it expired, how many cycles had been missed, etc. so that the developer consuming the API could make an independent business rule decision.
Typically, API syntax is very much a how thing to be determined by the developers. However, in this case, it was really a what and needed to meet customer needs. Unfortunately, this perceived encroachment did not sit well with some people.
So, we refined our model a bit. In addition to What and How, we added a concept of “Specific What” to capture the idea of a business requirement to meet customer needs that encroaches on the technical implementation.