I’m often asked about Buy, Build or Partner (BBP), and specifically, how to best fit it into the ever-growing list of product management duties. I call it a necessary evil, as almost each and every single product manager has to contend with it for better or worse.
Some product managers will look at this title and ask, “So what does this have to do with product managers and our roles?” Read on and find out why your role and actions can impact a successful channel program and increase the your product adoption.
Product managers often place the cart before the horse. We love to think about the product, the features, how “cool” the UI is, and how we can make the product better.
Steve Ballmer was once quoted saying, “The lifeblood of our business is that R&D spend. There's nothing that flows through a pipe or down a wire or anything else. We have to continuously create new innovation that lets people do something they didn't think they could do the day before.”
I recently worked with a great product management organization—great in the eyes of the management team that assembled them, at least.
This inbound team of heavily technical product managers was responsible for the 2-3 year product roadmap for the company. As a result, their main constituents were the entire engineering community and, more specifically, the software and hardware architects interspersed through that community.
“Roadmap” is the most overused word in product management because everyone asks for one. Every stakeholder wants a roadmap because it addresses different needs for different people. Executives want to know the strategy, sales want to know the timeline, and what no one seems to realize is that a roadmap doesn’t solve a problem or deliver a requirement.
Although some may believe peer review is a practice reserved for academic or scientific communities, I believe it is a valuable tool in product management.
Peer review is about quality—a structured approach to understanding whether or not your ideas fall into the category of worthwhile, meaningful or correct, and the benefit of colleagues evaluating product requirements and definitions.
You may remember the last time, I posted on selecting product management frameworks the big questions were which is the right one, how to implement a black and white concept in your team and what are the keys to getting a return on the investment?
Last time we determined that Product Management Frameworks can’t be implemented in in black and white; your team has been in place for years there are pre-existing processes that are not easy to change.
I, recently, had a chance to participate in a class on Design Thinking. Design Thinking, you ask? This course, sourced from the Stanford School of Design, presents some interesting concepts they clearly are quite excited about. The term, I’ve noticed, has also started enter the lexicon of product management. Why would this happen?
Inbound product management functions have traditionally focused on market and product definition, the quantification of priorities to address problems found in those markets. It also provides guidance in the form of product requirements, value propositions and the related pricing, margins and forecasts necessary to justify investments in products that satisfy unmet needs in those markets.
Design thinking proposes that these elements are not really needed. Rather, the concept suggests that the only requirement is that the maker/developer merely collaborates with the user using structured methods of development. The resulting products are then clearly aligned to solve the user’s problem.
In 2012, a financial technology (FinTech) company found itself in a quandary. The product management team was stuck using an ad-hoc approach to get new products and enhancements to market. Amidst its nearly 100 product managers, the product leadership team admitted they didn’t know what type of essential product management framework process to adopt and use. They asked if I could help them in product management consulting. Shortly after, a second, company in a different industry sector asked the same. Naturally, I said yes, and realized that these companies would have to take very different paths to solve the same problem.
The projects caused me to pause and reflect. How do technology companies get off track, and why is it so hard to course correct? At what stage should the company begin to use a more formalized approach to get software from idea to market? What outcomes can leadership expect if they make this investment?
Passing the Knowledge - Find your Answers to the Top 10 Product Sales Questions
It isn’t easy for a group of product and marketing to pass their accumulated knowledge to the company’s sales force. For many, doing so is unfamiliar territory. Why? Because the motivations and perceptions of a successful sales force is orthogonal to product marketing functions.
Let’s take a look at why this is.
Prior to my career as a product manager, I was a quota-carrying, territory-based sales guy in business-to-business accounts. I was on the receiving end of product management training many times. Of course, the product managers are enthusiastic—they need to be, but I didn't like the training because they weren't answering the Top 10 Sales Questions.
Most product managers understand their products inside and out; they have deep product knowledge and they’re usually pretty good at translating techie-speak into value propositions. What product managers do not understand is that this knowledge alone is insufficient for motivating the sales representative to get it sold.