Managing the Madness of Product Management

If you’ve ever seen the picture of the Hindu Goddess Durga, the Divine Feminine, with 8 hands that has a tool/weapon in each, you’d wish for the same if you are a Product Manager.

Being the glue, the messenger, the translator — and every other role one can associate with someone who has to bridge the gap between ideation and execution — I sometimes feel like a living-breathing Bifrost, connecting different realms, where each realm has its own ‘time’ and ‘language’. One day can be 20 hours or 200 years!

How is that possible? Quite simply like this — the business and marketing/sales teams are always going to be future focused or on-the-current market trends and needs. The development teams would be engrossed in the requirements that came out a month or two ago. So while team is at X release, Business is already at 3x.xx release.

If my mumbo-jumbo has confused you, simply put, Business and Development live in parallel time planes. What the development is finishing today, is what the Business had in mind maybe two months ago and is now engaged in solving a new set of problems.

So as a Product manager, how do you ensure that–

• Business and Development understand each other
• Nothing is lost in transmission across the parallel universe
• Development team is aware of the future needs without being overwhelmed
• Business knows the pace of development

Here are some practices that I have created over the years that help me keep my head above the water-

What’s in a name?

With due respect to Shakespeare, I would say, a lot. Name is an identifier, a placeholder and a reference point. It is how homo sapiens are able to communicate and identify. Be it the object of our affection or frustration.

So naming things with the appropriate context, having a taxonomy or a dictionary for the terminology that everyone understands and agrees upon is one of the most crucial aspects of successful communication between Business and Development.

This is achieved by having the business explain domain specific process and use references where ever applicable. And then document whatever business defines. This will help you create a Glossary for future reference as well.

On the other side, emphasize to the Development team the need to keep data models and structures as close to the business entities and process. The more the overlap, the easier it is.

But this is only half the story. There will be terminology, process and entities that the Development team will create. These are mostly implementation strategies for the business needs, such as daily background jobs to update status, a dynamic framework to handle new requests, a process for making old data obsolete.

So if a team frequently uses these to explain product behavior, effort estimates or even the way for absorbing change requests, then ensure that you explain the same to the business and share with them the terms and process.

And ensure documentation.

Look Ahead and beyond the scope of sprint

Have you ever seen any developer running around pulling their hair apart screaming ‘If only I knew that (change) 3 weeks ago! I would not be redoing all of that now!!’.

Agile recommends having a groomed product backlog of ‘2 Sprints’. It works brilliantly to allow the team to plan for capacity and work. I recommend going a step further and sharing the Product roadmap with the team once a month; 40 days tops.

Why, you ask? My reason is quite simple-

The ‘2 Sprints’ backlog will give the team a view of the next 2,4 or 6 weeks depending on your Sprint duration. This could be either too myopic or too far away in the future to make sense in the present.

So to keep things consistent across different durations, I find that presenting the roadmap to the team once in 30 or 40 days lets the team know what the ‘near future’ looks like, without being overwhelmed with intricate details. Most importantly, they will know if any major technical or design considerations should be invested in or not.

And that will save everyone’s effort and cost, with team morale as a bonus.

Ctrl+F5 a.k.a Refresh Their Memory

Did I mention the chaos of Release X and Release 3x.xxx? Ya I did.

Sprint Demos are the reunion ground for everyone to come together. It’s where the nerdy development team expectantly awaits to meet the homecoming King and Queen and show the (heroic) problems they solved. But what if the popular ‘group’ can’t recall the nature of that problem? *Pop* Bursts the bubble of happiness.

High school references aside (I’m obviously watching too many Netflix originals), when Business has moved so far ahead in requirements, there is a chance that they have forgotten the details of what the team has worked so hard to build.

I find it helpful to send a refresher note to all those attending the Demo with the following-

• The sprint goal, recounting the Stories or Epics that will be showcased
• The business problem and challenges
• Assumptions and agreements, if any, that may have been made for the technical implementation.
• Any work that may have been committed to be ‘not done’ or partially done for that Sprint.

Some of this may not be seem ‘practical’ for early stage startup companies that are still trying to figure out their users and the market because of which changes come in frequently. But there too one can achieve far more cadence and method to the madness with these simple tactical steps.

This is my life jacket that helps me navigate the deepest of waters. I would love to hear some of the things that help you likewise.

I wrote this blog for our Medium Publication- Unboxing Product Management. The publication is a weekly column by leaders of Quovantis to share their learning and knowledge with the world. If you liked reading the blog, clap your heart out and help others find it.