You can feel the energy in the room earlier this week as we huddled around a projector at a two-day company offsite. Our company is doubling in size every year, we’re hiring new people all the time and growing interest in more globally competitive innovation and frugal innovation is feeding us an opportunity to become a very large company. The mood is naturally upbeat as we launch the offsite with a review of company performance.

Throughout those two days I must have heard a dozen stories about different customer prospects and what their pains were in the innovation cycle. Though different prospects were interested in specific features, there was a theme that strung across nearly every story.

There’s a fundamental disconnect between product managers and their boss that’s caused from the way the two groups communicate.

• Product managers are most concerned with building products faster, because that’s what’s communicated from the top-down and what they live and breathe every day; requests for more product features than there are resources to develop and tight deadlines.
• Despite the communication from the product manager’s boss about deadlines and features, what keeps your boss up at night is making products that customers want – products that will sell. When 50 percent of product launches are a failure, the risk and pressure are high to deliver.

Neither group is incorrect and both are important issues, but everyone can work a little better if we better understand each other.

Executives can’t have all the features they want – they have to choose based on resources and priorities. Find a way to communicate the tradeoffs and where they might have to give up a feature. Your boss shouldn’t be the only one sweating whether the product will sell. Get in the game, join the discussion, get customer feedback and contribute to getting the RIGHT features into the product.

Even if all you hear from up the chain is pressure to meet deadlines and develop products faster, you can bet if we ask your boss what their biggest concerns are, they’re worried about products that sell.

Congratulations to April Dunford of Rocket Watch for winning the AIPMM’s Battle of the Bloggers event early this week.  Check out her winning presentation slides, and see why she deserved to win.

Also, congratulations to Ethan Henry of On Product Management, Tom Grant of The Heretech, Ivan Lybbert of My Product Management Opinion, and Ivan Chalif of The Productologist who were 1st, 2nd and 3rd runner ups’ respectively.

It was a huge honor to be even nominated with this esteemed group, and I feel very fortunate to have met so many smart, funny and genuinely nice fellow bloggers (a personal thank you to April, Brian, Michael, Ivan L., Ivan C., Tom, Marsha, Gavin, Janey, and Ethan for making me feel so welcome). I made new friends, and I know that I can learn so much from my fellow bloggers, and what makes them successful.

I have to say, it was the most fun, entertaining and hilarious event that I’ve ever participated in, and I think the bloggers might of even enjoyed it more than the audience could of.  Credit all goes to Therese Padilla of AIPMM for coming up with such a great idea.

I also heard a rumor that the AIPMM might also hold the 2nd Battle of the Blogger event next year, so don’t miss the chance to see the fun and antics first hand, and besides, Tom Grant might even make a repeat performance of bringing his teddy bear again.

A couple of weeks ago, Dave West, Forrester Sr. Analyst hosted a webinar with us, entitled, “How Agile Value Management (AVM) can remove risk earlier in your agile process”.  Dave spoke about the benefits of removing risk earlier in your agile process, and streamlining key life cycle friction points between your product teams, analysts, engineering, manufacturing, and customers.

As is usually the case, we received more questions than Dave was able to respond to during the duration of the webinar. Dave has very graciously responded to your unanswered questions, which I’ve included below.

You can also listen to the full webinar replay here.  You’ll also want to follow Dave if you’re not already, he’s very fascinating guy.

1)      Where does innovation in untested or unknown area fit into the value equation?

That is a really interested question. It is hard to know the true value of innovation, but there are techniques such as innovation games that provide a mechanism to at least prioritize one thing over another. The truth of the matter is when delivering new stuff (brand new, innovative product or service) the best thing to do is get something out and test the response ( measure in a controlled way) and then accept that change will happen. An example of this approach is what MS do with their extended Beta – The product is released almost a year before RTM, but to a small select group who provide LOTS of feedback and comment. During that exercise the value of the features are assessed and measured.

2)      What is the value of Documentation in regards to the Agile Methodology?

The problem of documentation is that it is often aimed at two very different audiences. Firstly it is used to drive development in terms of requirements, designs, etc. Secondly it is used to describe the system for maintenance and support. These are two very different audiences. The result is documentation that is neither and good for nothing, thus it gets out of date and becomes irrelevant. Thus on most projects we see Agile documentation driving the development of great software and testing it in terms of stories, simple designs and test materials. The maxim for this documentation is just enough to enable the team to move to done, and is supported with tacit knowledge. In parallel other documentation is created to support the process of support – this is written by professional writers aimed at ONE audience with ONE set of needs.

I was working with a customer this week doing a process diagnostic. One of the things they happened to mention is that they miss waterfall. I was surprised as these days all I hear is how everyone wants to be more agile.

I asked for more, and the anecdote provided was that they cannot get commitment to specific Features being delivered as part of a release as they could in the past. Their requirements process had migrated from Features to User Stories where if they asked for a Feature the first response was give us the stories and then when asked when they can get the features they were told “when it’s done”!

Now of course, for any company where success is meeting market needs, this is not desired. So after that phase of the diagnostic was complete, I mentioned we could help them create an environment where Features and Stories can coexist and a release commitment could be created. I do not see this as breaking agile simply making it work in an environment where the Product Owner needs to meet the team’s needs but also the needs of a commercial company where commitment to stories is not enough. Do you agree?