Archive for May, 2010

When not to roadmap (hint: Lean Startup)

[tweetmeme source=”chenelaine” only_single=”false” service=””]

Recently I had an interesting debate with an old friend about product roadmaps.

Before I share that story, I should disclose that I am a strategy junkie and a compulsive planner.  I make lists in my sleep.  I have driven the product strategy and maintained the product roadmap for the last several companies I was associated with.  A roadmap exercise is the best way for the product team to get out of the weeds and see the forest, and everyone I worked with knew where I stood on that topic.

So I found it funny that I ended up waxing lyrical about a completely opposite position in this debate. My friend was arguing for the need for a roadmap in a startup in its infancy (6 months after incorporation), to lesson thrashing and reduce waste.  I instead argued that for such a young startup, a roadmap is worthless.   Instead, the company should direct its energy towards testing their ideas with customers until the company hits the killer idea.

In such a young company, thrashing is not waste.  Overinvesting is.  On this point I am 100% in alignment with the Lean Startup philosophy.

In Peter Bregman’s words, sometimes not having a plan can be the best plan of all.  Only when the killer idea is well defined, the target market has been identified and quantified, the personas have been decided on, and a product platform has been developed, does it makes sense to work on product strategy and create product roadmaps.  That’s typically at least 1-2 years after incorporation.

I often come across as a roadmap nazi because I harp incessantly about its importance as a symbol of a well thought out product strategy.   But like all debates, absolute statements are silly.   If your company is young, iterate until you are in a position to grow. If you are in a growth state business, then by all means, roadmap and plan to your heart’s content!


Conflict of interest

[tweetmeme source=”chenelaine” only_single=”false” service=””]

I recently ran into a conflict of interest scenario in two separate situations.

Situation 1 had product management pitched against engineering. Product management wanted to get more bug fixes into the next release. Engineering wanted to stop changing the code so SQA could actually finish what they were doing.  The issue? I was filling in for the product manager while serving as the head of engineering.   In the end, the conservative voice of engineering won, simply because we didn’t have the resources to run yet another full set of regression tests on a new deployment.  But I am not sure the best decision was made about the stuff we left out this go-around – maybe I could have made it work if someone else was there to push back on my decision.

Situation 2 had development pitched against SQA.  Development wanted to get a beta release out for field testing sooner than later, to hit an externally imposed deadline. SQA thought it was absurd, as the beta release hasn’t  been put through its paces in beta testing.   The issue? I was filling in for both development AND SQA.  I wrote the code myself and badly wanted to see it exercised in the field.   I ended up ceding the release decision to Sales (with predictable results – the beta release is now in field testing.)  In hindsight, I pretty much made the de-facto decision to release the beta build myself.  No sales organization I know would turn down a demo build with new features, as long as it looked like it worked at least once.   Just thinking about this makes me cringe.

My key takeaway is that no matter how short staffed we get, it is absolute lunacy to have the same person fill roles which are meant to check on each other.  It’s a recipe for bad decision making.  Better to let deliverables slide out in time than give up on the healthy tension that helps ensure a high quality of output.

I’m OK with the first decision, but I feel nauseous each time I think about the second. I hope to God that Murphy’s Law is kind to me just this once, and that nothing bad happens with my horrifically under-tested beta release.

Where should product management live in an organization?

[tweetmeme source=”chenelaine” only_single=”false” service=””]

I attended Product Camp in Boston over the weekend and the topic of where product management should live in an organization came up once again.  I had a blog post about this on my abandoned old blog, so I dragged it out and looked at it.  I realized I now agree with bits of it and disagree with other bits of it.

On the bits that I agree with, I continue to stand by my basic tenet:

Engineering and product management must be peers.

In my old blog post I went on to advocate that Product Management reports directly to senior staff as peers of Engineering and Marketing. I still think that’s the best possible structure.

However, the reality is that very few startup companies and small businesses are equipped to support this structure.  The CEO is typically terribly overloaded and is often not equipped to give the head of Product Management the support that he or she needs on a regular basis.

At the time I thought the next best thing would be to have Engineering and Product Management report into a Product organization which then reported to the CEO. With one more company and a couple more years of perspective behind me, I no longer believe this is practical for a small company. When the company has 20 or fewer people, 3 product execs is 1 exec too many. A much more practical solution is to have product management report into either Marketing (prefered) or Engineering (as a last resort).

It all depends on the people we have in a company and the skillsets they bring to the table. If Engineering has access to resources who are great at understanding customer / buyer needs and wants and can generate their own functional specification as a service to product management, then I think a more strategic product manager with substantial product marketing skills would make sense, and that person would work well in the Marketing organization. Conversely, if product strategy and roadmapping is well covered by other executives, and the need is for detailed product design and specification, then a technical product manager reporting to Engineering could work just fine.

I still believe Product Management should have a seat at the senior staff table together with Engineering and Marketing. But I think other less optimal structures can be made to work. The trick is to clearly define the role within the organization and make sure the product manager can succeed in their role.

Twitter Updates


%d bloggers like this: