More than 20 years ago Fred Brooks published a seminal essay on the nature of software, called “No Silver Bullet: Essence and Accidents of Software Engineering”. If you’ve never read it I’d highly encourage it, as even though it’s ancient by the standards of our industry, it’s still amazingly relevant and gets to the heart of why creating great software is so hard.
I work exclusively with commercial software product organizations. Organizations that must create products and services that thousands or millions of users must make an independent decision to use or buy. This is in contrast to custom software companies that create software purely for internal use. But since many companies have moved from custom to product software I often find companies with behaviors and practices inherited from their prior life as a custom software company, but one practice that really deeply bothers me is when I find a product organization that is outsourcing core competencies.
In my last article, I discussed the situation where Product Discovery is essentially not discovery at all, but rather just a mad dash of just-in-time spec writing so that the engineers can be kept busy. I discussed how important it is that the date not be driving everything at the expense of the value of what will be created.
For those that haven’t heard the term before, “feed the beast” refers to one of the most common problems with product teams, and one of the top reasons for failed projects. It’s very easy to spot. If you find a product manager that is scrambling to finish up his PRD because the developers are freeing up from their current project on Monday and the very thought of the developers not having a fresh spec ready to go sends the product manager (and especially senior management) into a panic, that’s what we call “feed the beast.”
For a startup, where there’s typically just one product team, it’s not too hard for the leaders to keep in their heads a holistic view of the product. However, this quickly becomes much tougher as the company grows first to a larger product and soon to multiple product teams. One of the challenges of growth is knowing how the whole product hangs together.
As readers of these articles know, I am a big fan of high-fidelity prototyping and user testing on current or prospective customers. These techniques form the basis of Product Discovery; it’s the key to discovering the minimum viable product – a product solution that is valuable, usable and feasible (see www.svpg.com/product-discovery/).
Over the last several months I have been working with some clients to revisit how they do product portfolio planning. Essentially the process they use to determine where to invest and how much. I’ve discussed the purpose and the common frustrations with how product planning is done in most software product companies, as well as explored the root causes of these frustrations. We’ve looked at several specific techniques, and we’ve considered the lessons we can learn from the VC industry, incubators, and some companies that have demonstrated the ability to perform this well.
I need to interrupt my series of articles on product portfolio planning because over the past week I learned of three completely different companies that all had fairly disastrous product results for the same core reason: they delayed talking to customers until it was too late.
My husband and I were watching the Daily Show the other night on our DVR, fast forwarding through commercials as we usually do.
Out of the corner of my eye, I noticed the text "Palm Pre" and yelled, "Back up!" to my husband. I hadn’t yet seen the Pre and was interested in Palm’s latest ‘Hail Mary.’
Several people pointed me to this great little talk by Jeff Bezos, the founder and CEO of Amazon. If you haven’t watched this yet you should. I thought his talk did a great job highlighting a few key points that pertain to my current theme of product portfolio planning and I wanted to emphasize them here: