I haven’t spent much time doing pure play product management posting in a while, so I thought I would today. I’ve been doing a bunch of leisure surfing and looking at a bunch of great stuff online and challenged myself to think about what it takes to transition a technology into a product. While I didn’t come to a great deal of conclusions, I think I’ve come up with some reasonable litmus tests for consideration:
- Does your product have more defects than enhancement requests?
- Can the users manage their own product experience?
- Does everyone tell the same story about the product inside your organization?
- Do customer users out number the support staff?
- Can your product be contracted the same from sale to sale?
- Are your training materials for the organization more lengthy than the prospect presentation?
- Do you use the words scripting and framework more than configurable?
- Does a product error message require research from development or is it in the knowledge base?
- Are there more sales tools for the product than product managers?
What questions do you ask about your product?
Blog: A Litmus Test: Transitioning Technology to Product: I haven’t spent much time doing pu.. http://tinyurl.com/384cjh
A technology becomes a product when you have a client paying you to build a custom application on top of the technology, or you’ve built a product on top of the technology. Once you’ve built your product on top of your technology, the product manager has to manage both separately.
If you have not built a layered architecture and you are selling your technology, it unfortunately is still not a product. Unproductized technology is a hard sale. If you are pushing it at geeks, don’t expect to make revenues.
[…] couple of weeks I’ve been just crazy busy with work, but I’ve also been pitched several technology projects to participate in from a labor perspective or to throw a little cash at. After sitting in these […]
[…] Product Management is different in each organization, with different title lengths and varying levels of P&L influence/accountability. Some are business owners and others manage requirements – some do all, while the common theme exist “You have to keep things going right way and manage priorities”. PM’s are responsible for optimizing the cross functional interfaces, customer value and competitiveness of their product in the marketplace and that creates a bunch of Dilbert moments. PM’s just dance around the organization and try to make things work. In the more technical organizations these folks are constantly managing the delivery of IP to Product. […]