|
|
Blog Articles
Product Discovery for Non-Technology Products
Article: Product Discovery for Non-Technology Products
I’m often asked whether or not the concepts that I advocate and write about are applicable to non-software products as well as the consumer and business internet services that I almost exclusively focus on. My answer has always been that I really didn’t know because in my career I have only built software technology products.
Dedicated Product Teams
In my last article I talked about the importance of knocking down walls, especially the wall between product management and engineering. In this article, I want to describe a technique that helps achieve this, along with several other significant benefits.
Knocking Down Walls
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.
Regaining Your Product Mojo
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.
Product Management as a Service Organization
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.
The Product Decade
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.
No Silver Bullet
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.
Outsourcing Core Competencies
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.
The Product Discovery Plan
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.
Feed The Beast
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.”