Thomas Edison, the alleged inventor of the light bulb (he wasn’t), famously said that genius is 1 percent inspiration and 99 percent perspiration. The same is true for product management. We can explore and strategize all we want, but if we don’t act on the findings and the strategy, all these efforts are in vain.
As the saying goes, the road to hell is paved with good intentions. In many of my interactions with various companies, it rapidly becomes clear that everyone knows what needs to be done and claims to want the right things to happen. However, for a variety of reasons, it stays with ideas and the execution never gets beyond ambitions and some half-baked attempts.
In my experience, the main reason that execution is so hard is threefold: personal inertia, organizational constraints and the gap between saying and doing. The first constraint that I see quite a bit is the inertia that all of us have in our lives. We all entertain a set of habits, both personally and professionally, that, according to research, dictate up to 95 percent of our actions. Even if we’re all convinced that we want to do things differently, breaking out of the trigger-action-reward pattern can prove to be extremely difficult.
The second main reason why executing strategies or changes in general is so difficult is that modern organizations are optimized to an extent that every individual, team and function is tightly integrated with other individuals, teams and functions. The organizational structure dictates certain processes and ways of working, deviating from which is extremely difficult as it breaks everything in the chain.
This is often exacerbated by all the tools that were introduced or developed to automate part of the processes. Automation is amazing and very important, but the fact is that many tools dictate a certain way of working, the changing of which often requires changing the tools and their incarnations of the ways of working.
The third reason is concerned with the gap between what in management literature is referred to as espoused theory versus theory-in-use – the gap between what people say they do and what they really do in practice. This is found in all parts of life but even more so in corporate contexts. There have been several situations where it became obvious to me, after a period of trying, that even though the team claimed that they wanted to change, deep down they really didn’t want to and consequently nothing happened. As a consultant, this is when you have to fire your customer and tell them that there’s nothing you can do to help them.
For product management, the execution activities are typically concerned with interacting with the teams involved in building the prioritized functionality and the enabling infrastructure, the release of new software versions, the collection of feedback from the field as input for the next iteration of exploration as well as the aggregation of data to establish business impact.
First, product managers work with R&D teams to realize the prioritized functionality and implement the declared strategy. The engineers in these teams are human beings and as such, they need to know why they’re building what’s asked of them, how they know whether they’re successful and in what way the functionality should be realized. As product managers typically are closer to the customer than engineers, in a way they become the proxy for the customer. Of course, this isn’t just the case for teams building functionality that’s directly used by external customers but also for teams working on infrastructures that are required to get things out to external customers. In the latter case, the product manager is concerned with an internal set of customers whose demands to meet.
Second, while DevOps is going a long way to take the drama out of releasing new software to customers and products in the field, there’s often still a bit of tension and careful monitoring when new releases go live. Although the more operational parts are managed by operations staff, the performance of new functionality and the response of customers to new functionality released is a key focus area for product management. In the end, we build new functionality with the intent of delivering value and not just more complexity and crud.
The final activity is concerned with collecting qualitative and quantitative feedback from the field. It is best practice, in my view, to predict, preferably quantitatively, what the impact of a new feature or some novel functionality will be. In addition, when the level of uncertainty as to the impact is very high, we shouldn’t develop the entire feature or functionality in one go but rather build thin slices and proceed iteratively, evaluating with every release whether the KPIs are moving in the right direction or not. If it turns out, after one or two releases of partial functionality, that the impact is negligible or negative, we should stop development and remove the related code from the system.
Although exploration and strategy development are critically important to get right, these have no impact whatsoever unless we execute. Many view execution as the easy part, but in my experience, this is where the rubber meets the road and all the challenges surface. For a variety of reasons, many of us, both personally and professionally, get stuck in the gap between strategy and execution. Product management is concerned with working with teams to realize the strategy, carefully tracking the impact of new software releases and using qualitative and quantitative feedback to continuously adjust and optimize the release content for each DevOps iteration. As Lawrence Bossidy so beautifully said: “Execution is the ability to mesh strategy with reality, align people with goals and achieve the promised results.”
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
