“Don’t go into solution-mode just yet!”
A developer may hear this a lot. The fact is, like everything else around us in the world, when faced with a challenge, we try to provide a solution. This “Solution Mode” is our way of short cutting into the “How” by skipping the “What”. So, a good Product Manager should encourage our developer to start exploring the “What” in figuring out what we are trying to achieve so that the context is defined first.
I Want Everything
But we can demand any “what” … can’t we? With a talented and enthusiastic team, conversations can quickly become very aspirational around “what do we need”. While there is value to lay out the art-of-the-possible and extend the context by going deep into answering the “what”, I subscribe to a more practical approach. It is of having a foundation of tools and principles in front of us before we go into any discussion around “What do we want to achieve in this feature?”.
Boundaries
This is where the opinionated version of product development comes in. The one that is predicated on a set of design principles and solution architecture guidelines. The one that we can reliably test its stamina through time. Based on Martin Fowler’s Design Stamina Hypothesis, we know that we can only go so much without a good emphasis on the design at the start of our development. And this design, which reduces technical debt in the long run, is what I am referring to as opinionated approach to product development.
So, if we follow as said above, what exactly happens to our developer with their “solution mode”?. Well, they need to communicate the essential architectural mandates prior to the meeting. This ensures the discussion is bounded by those principles and available tools.
What Happens to Innovation?
Now, with this approach, we are clearly introducing certain limitations and playing field rules from the beginning which may become a speed bump to innovation. So, there are a few caveats and considerations which I need to point out:
- Embrace Evolutionary Architecture
- This is on one hand based on Microservice Architecture and Service Oriented Architecture and on the other hand allowing teams to own the feature/product. This fundamentally restricts one-design-fits-all architecture and gives the team authority to build more freely.
- Business/customer value should rule the feature itself
- This puts a realistic boundary around the feature itself and avoids the team falling into the rabbit hole of the art-of-the-possible.
- Allow experimentation
- Data/value-driven experiments should be systematically encouraged so that teams can test hypothesis and innovate based on prototypes. The outcomes of experimentations should then be evaluated and brought into the design if passed.