On Product Management

NOTE: The following is a guest post from Ilya Bagrak. If you want to submit your own guest post, click here for more information.

- -

Boiling Down Agile

When I take a look at agile programming from far enough away, I am astounded by the powerful ideas it brings to software engineering. I am not going to regurgitate all the benefits and detractions of agile, but I will restate it in simpler terms or as I tend to understand it from my product management perch.

• Agile takes a medium-term engineering goal, decomposes the delta between the current state of affairs and the objective into bite-size chunks, and then chews through one chunk at a time, learning as it goes along.
• It increases the opportunity for self-correction by structuring the learning such that the team can apply the things that it learned in one iteration to the one that follows.
• If self-correction happens often enough, we arrive either at an engineering success or at a well-supported argument why a goal cannot be reached.

Arguably, you can’t do much better at optimizing engineering resources regardless of whether you call it agile, waterfall or something else entirely. And this brings me to the original reason for raising the agile specter:

Can the above principles be applied to product management?

Agility in Product Management

I believe that some agile principles can be applied to product management, but we need to take note of a couple of terms listed above and how they are different for Product Management. These terms are “team” and “iteration”.

Team

Agile methods place a lot of focus on intra-team communications. It’s all about making sure that engineers get to bounce ideas off one another other, sanity-check their estimates with each other and work on the problems collaboratively as opposed to in complete isolation. Naturally, a lot of agile engineering deals with prescribing specific agile roles and the responsibilities that go along with them.

Contrast this with Product Management, which is often a “lone ranger” role. You do it all, with few team members, but usually in collaboration with various external stakeholders.  For better or  worse, these external stakeholders are all embedded in their own distinct workflows (sales, marketing, senior management), so they cannot be easily compelled to play by a uniform set of rules (as required in agile development).

To work with these stakeholders,  it’s easier to think in terms of inputs you need from them and the  outputs you must provide to them to move forward in the most efficient way possible. So in the end it’s all about communication as well (isn’t everything?).

How can this way of thinking be translated into action? It helps to sit down with different stakeholders and write down and agree with them about what they expect from you and what you expect from them. Trust me, I’ve done this exercise and it helps a lot in streamlining communications. You’ll also find that people are strongly motivated to sit down with you because there is clear value in this exercise for them as well.

Iterations

This is the other term to consider. Earlier I referred to iterations and the medium-term goals that engineering focuses on. To an especially cynical product manager it may seem natural to partition software development into sprints because all engineering activity is homogeneous, whereas product management activity is heterogeneous. The argument may be that it’s harder to march in lockstep since in product management you advance on many fronts at once.

But, there is nothing natural about splitting engineering work into bite-size chunks because work items often exceed the length of iteration and/or don’t start at the start of iteration. In my experience this is a tremendous source of agile headache. So in the end it’s not done because it’s a natural thing to do, it’s done because the benefits outweigh the downsides. The same holds true for product management.

If you have many concurrent and heterogeneous activities in various states of completion, nothing should be stopping you from checkpointing yourself every so often. To deflect the obvious criticism, let me say that I am not talking about scheduled reporting to your boss.

Instead I am talking about self-correction and squaring your progress against your own plans.  The hope is that by increasing your opportunity for self-correction you also increase your chances of reaching your goals. The reason this is difficult for product managers  is that it’s hard to pause just to have a conversation with yourself.

How long should agile product management iterations be? Think in terms of raw percentage of time spent planning and updating plans. This in my view should not exceed 10% of all work you do. If it takes you 1 day to plan for the next three weeks, that’s 1/15 or 6.7%, which looks just about right to me.

Putting Everything Together

If you’ve worked closely with engineering, you know that engineering gets a lot of flak for missing deadlines and providing inaccurate estimates of work to be done. And these are precisely the problem that agile programming practices try to address.

However, I often see Product Management get less criticism than engineering for the same missteps. We are more easily forgiven for messing up the little stuff or steering off course temporarily as long as the overall direction and trend is acceptable. On the other extreme, when product managers fail, they fail spectacularly and with much more serious repercussions for the person at fault.

Why is this the case? I think the main issue is that our success as product managers is more amorphous and difficult to define than engineering success, and any agreement on how to evaluate product managers has proven elusive. It’s really a function of the multiple hats we wear, the lack of opportunity for repetitive course correction along the way,  and the fact that complete and utter product failure just takes more time so it occurs less frequently, which in turn creates the perception of greater leniency.

In Conclusion

What I like about agile programming is the commitment to improving the metrics by which engineering is ultimately judged. As a consequence of inherent differences between product management and product engineering, not everything that is agile can be applied to product management.  Still I do believe that a combination of:

• more structured product management communications,
• iterative planning and self-evaluation,
• finer grain (as opposed to all or nothing) performance metrics

can all lead to better product managers and better products.

- -

Ilya Bagrak (@ibagrak) is a product manager and a budding internet entrepreneur who shares his time between Moscow, Russia and Silicon Valley, California. He also blogs about product management, entrepreneurship, and technology at codercofounder.wordpress.com.

Leave a Reply Cancel reply