There’s something to be said for learning lessons “the hard way.” When you suffer as a result of a lesson, it may be more permanently imprinted into your brain. When you learn something with only an abstract understanding of the consequences of failure, there’s a risk of the lesson not fully sinking in. Or maybe that’s just something we tell ourselves to feel better about having made a mistake. We chalk it up to a learning experience in order to make that kick in the teeth taste a little sweeter.
7 Product Management Lessons From Real Product Managers
Regardless, as is true in other disciplines, product management has a way of delivering lessons that leave an indelible mark on young product managers, scars that turn a newbie into a veteran. Here’s a quick tour of my own hard-fought lessons learned.
Lesson 1: You can’t always get what you want
And with all due respect to Mick Jagger and the Rolling Stones, you don’t always get what you need, either.
This lesson was my introduction to the product management version of “life isn’t fair.” In the late 1990s, I was managing a new product concept at the Philips Multimedia Center, a product incubation facility aimed at helping the consumer electronics giant figure out how best to incorporate digital technology into its audio-visual, device-centric product offering.
My product, a “digital family center,” was based on the idea of putting a bigger screen on a Palm Pilot and hanging it in the kitchen. We stripped it down to a few very basic functions – family calendar, phone book, and lists (shopping, to-do, etc.) – based on research into how people organized their family life. Since these were the days before smartphones, it even had a little printer to spit out a list to take to the store with you and a “virtual dinner bell,” a feature that would send “come home” messages to all of the kids’ pagers.
The digital family center concept and 19 other new product ideas were submitted to a large-scale study to determine which had the greatest market potential. Or at least that was supposed to be the idea. As it turned out, the purpose of the research was pretty unclear.
The digital family center scored second out of the 20 concepts. We were at a stage where we needed $5 million to go from foam to working prototype, which was not a very large investment for a company like Philips. Based on the fact that we were making a “modest” request for an idea that scored so highly, I was certain we would be able to continue the work.
That’s not what happened. They gave the money to another product idea, a digital photo album that showed pics on your TV. It scored 18th on the list of 20 product concepts, but it was closer to being a shippable product and already had a team around it. The digital family center was shelved, and the digital photo album never made it to market anyway.
The lesson I took away from that experience is to remember that investment and other decisions are made for many reasons by people who are in a position to affect your product directly. Sometimes they go your way, and sometimes they don’t.
The hard lesson is to learn to accept those decisions for what they are – factors outside your control – and to move on to deciding how to respond to those decisions rather than react with denial, defensiveness, resentment, or resignation. Product managers face a steady stream of situations they must learn to deal with that are outside their direct control. A product management core competency is learning to take in, process, and deal with setbacks.
Lesson 2: Design decisions matter, some more than others
Attitudes have changed in recent years about re-writing whole sections of code or even entire products based on a need or desire to change architectures or take advantage of a new development in the technology stack. This work falls under the euphemistic term “refactoring.” It’s one thing to take on this work to take advantage of an opportunity. It’s an entirely different thing to do so out of necessity because you’ve designed yourself into a corner.
After Philips, I took over product management at a start-up selling an interactive video suite. One part of the portfolio was an authoring tool, which included the ability to import various videos and other assets to piece together into a clickable experience. The total number of assets for a single piece could be from dozens to hundreds depending on the length and interactive complexity of the final piece. After learning that there was no sort function in the asset management window and receiving customer feedback that it was difficult for users to find the asset they were looking for, I included the ability to view assets in alphabetical order in the spec for an upcoming release. My assumption was that it would be a quick improvement while we worked on other ideas for making the asset management experience better.
To my surprise, I learned from the tech team that alphabetizing the assets was not possible based on how they had implemented that part of the tool. Early in my career, my tech skills were insufficient to dig into the problem. I had to take the team at their word that it couldn’t be done. At the time, reworking the product architecture to support greater flexibility in the asset management window was unthinkable.
The pain in this lesson resulted not just from the fact that I had to tell the client that the feature was no going to be in the next release. But I also had to figure out how to live with this limitation in the future.
Ultimately, the design decision that led to the issue in my product was made before I was part of the conversation. The experience taught me the importance of having multiple views and disciplines participate in early product discussions. You’re never going to catch every gotcha decision. However, having product, design, and tech contribute to early discussions can help you avoid those design dead-ends. They are expensive to fix.
Lesson 3: Stakeholder management can be tricky
Product management is famously a field requiring the ability to influence people and organizations over whom you have no authority. All of the above fall into the group known as stakeholders. I think of them as parties whose work impacts your product.
This relationship means that stakeholders will have (or want to have) some say over the product. Depending on where a stakeholder sits on your RACI chart (real or virtual), the actual amount of that say varies. However, relationships with distant stakeholders can create issues if not handled effectively.
And there are so many ways to mess it up:
- Like the time a subject matter expert berated me for deleting a message without reading it even though the product I was building heavily reflected his input. That’s how I learned the preview pane in MS Outlook doesn’t trigger read receipts, or at least didn’t at the time.
- Or the time I agreed to allow a tech VP to keep the “source of truth” database schema on his laptop because he wanted to sharpen his data modeling skills. He checked his code into the repo every six weeks, throwing two development teams on two continents into chaos. That’s how I learned the importance of documenting the impact of stakeholder behavior on delivery schedules.
- Or a partner organization wants a long list of customizations to a white-label version of my product. And then they cancel the contract a month after work began on the changes. That’s how I learned the importance of contractual risk management.
This lesson is tricky because there are many ways to re-learn this one. It’s one thing to know that stakeholder management is tricky. It’s another to learn all the different ways it can go wrong.
Lesson 4: Product management requires taking risks
The number of product management job descriptions that don’t reference the importance of data-driven decision-making is vanishingly small. Reliance on user and customer research is a must-do for most PMs. More and more product teams are rapidly prototyping, getting a product into the market as quickly as possible. With the understanding that they are improving it over time.
These trends and more are all about removing as much risk as possible from the product delivery and management process. After all, if you base decisions on data, research, and feedback, you’ll be successful, right?
Unfortunately, no. There are no guarantees. A product manager can do all the “right things,” yet some risk is always present. A product manager has to be willing to say, “This is my best guess.”
The need for a best-guess decision comes up multiple times a day. Either the data isn’t available at the time, or it is inconclusive in terms of the insight it provides. And even when data is available, it’s not always reliable due to biases in collection or problems in study design.
Whatever the reason, a product manager must regularly make decisions in the absence of definitive data. Each and every one of those decisions is an assumption of risk. Sometimes it goes your way. Sometimes, you do your best to manage your product using all available data. Still, you make decisions that fail to achieve the executive team’s objectives. And that comes with significant risk. However, that risk is part of the job description.
The lesson that product management involves risk is unavoidable even after learning it. And knowing that risk is part of the deal as a product manager. However, it makes it no less painful due to the consequences of that risk.
The Ultimate Guide to a Product Manager’s Job
A career in product management delivers a wealth of lessons. The sooner a product manager learns these lessons, the sooner they can approach the job with a successful mindset.
