One of the great things about startups is that they are so small that there’s almost no organizational structure to speak of. Basically everyone there is just trying to create something people want.
In my last article, I talked about the problem where your product organization has been relegated to the role of a service organization, largely documenting the decisions and desires of others. I must have struck a chord because I received a record number of comments, mostly from people that felt trapped in this very situation and were anxious to see if there’s hope for change.
Probably one of the most common complaints I get from CEO's of mid- to large-sized companies is the lack of innovation and thought leadership from their product organization. They see the money they spend on product managers, designers, engineers and QA, yet they often see only marginal improvements to the business. Yet in most of these organizations, when I look at their roadmaps (these organizations rarely have product strategies), they’re littered with literally hundreds of specific features and incremental enhancements.
I don’t think there has ever been a better time to be a product person than right now. In fact, I’m fully expecting the decade about to begin to be far and away the most productive in terms of innovation.
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/).