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 adoption of your product(s).
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 PMs 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.
As product managers, we interface with a handful or even hundreds of programs, apps and tools to manage our work every day, so we’d like to recommend our Top 5 tools every product manager should have in their arsenal. I’m hopeful this topic will generate interest and discussion and turn into an ongoing series of posts and friendly debates.
Your challenge, if you choose to accept it: Have a (good) idea, pitch it, obtain approval, form a team, build a minimum viable product, present it and sell it. All resources are provided and paid for. No talk; all action. The catch? You have 54 hours.
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 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.
By David Shoaf
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.
Last year, 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 framework process to adopt and use. They asked if I could help. 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?
The problem for most software companies is how to maintain the initial speed and agility they needed to survive before success was achieved. Leadership will implement business processes to manage cost, risk and to maintain compliance. These processes usually come at the expense of speed and agility. It is not that processes are inherently slow; learning to coordinate with an emphasis on documentation and reporting saps the agility of a team.