What I talk about when I talk about product.
I’ve been trying to capture the product sayings and idioms I catch myself using day-to-day. Some of them were born trying to prevent myself and my team from making easy mistakes in Product Management. Others are phrases I picked up from great product managers along my journey.
Nurture a strong bias towards action.
Inaction leads to the waiting place. If you want to learn, test. If you need to get something done, do it. If you need a decision, choose. Each time you move forward you will gain momentum.
Don’t stay busy. Stay focused.
Busy implies a lack of focus. Focus implies that you are making choices about what is important and then ignoring the noise that would distract you.
It’s the scientific method: Ask a question, form your hypothesis, then test and learn. It’s not fail, fail, success (magic!).
I don’t like the “failure” framed mindset in Silicon Valley. “Don’t be afraid to fail” goes against our culture, our up-bringing and general mindset. I believe in the Scientific Method. It’s not a failure process, it’s a learning process.
Delight customers in hard to copy, margin enhancing ways. (Gib Biddle)
Gib is an outstanding product leader (see Netflix, Nerdwallet). This quote speaks to the delight you must to deliver to the users, the necessity for it to be unique, and the requirement to add value to the company — all in one sentence.
You are the quarterback, not the CEO. (Josh Elman)
I’ve long believed that the PM as CEO was misleading. A PM simply isn’t CEO. They don’t hire and fire the teams they work with. They don’t set company culture, and they don’t set company strategy. PMs earn influence through character, hard work and leadership. They are in the trenches with their teams — never above them.
If the user doesn’t get it, it’s not their fault — it’s yours.
If a user doesn’t get your brilliant feature instantly, never dismiss or fault them. Dig deeper. Why don’t you get it? How could it be better? Always take the blame; “I made it too hidden, I wasn’t thinking about X or Y.” By making your users feel respected and smart in your testing, they will give you honest, critical feedback. Cherish it.
Users are busy. You must make it extra easy.
If you need a walkthrough, coach-marks or call-outs, it’s probably too complicated or too hidden. Users have complicated lives — expect them to have fractions of a minute, or seconds at best, to understand your value pitch, your feature, or your app. Reducing hardship and roadblocks will earn you loyalty and love from your users.
Most users are snorkeling, not scuba diving. They dip in, take a look around and get out. How can you provide obvious value, quickly?
This is another way to say that users are busy, make it easy. I like the snorkeling/scuba analogy and find that it paints the picture well.
You are not your user.
It’s too easy to think “I don’t like this” or “If I were going to use this…” If you think this, stop and re-frame. Go back to the many user tests you’ve run. Think about those users — why do they love your app? How would they use this feature? What roadblocks might they hit? Then take whatever you built back to those users and test it again.
Stay observant. Notice the little things and delight in the tiny victories.
Sometimes we get caught up in the big picture, big metrics machine. It can be draining, even demoralizing, when you can’t move big numbers on lots of users. In these moments it can be useful to remember the user that sent you a thank you card for helping them. Or the simple UI update that garnered community attention. You don’t have to make galaxy denting changes everyday.
Remember that you’re in a bubble within a bubble. Don’t assume you know anything. Talk to your users. Test your ideas.
This is an important one in the Bay Area. How hard is it for a San Franciscan to relate to a user in Missouri? It’s not easy. Don’t assume you can put yourself in their shoes. Instead, talk with real users wherever they are. Test with them, and learn from them.
Make decisions. No decision is not an option. (Ken Norton)
A “no-decision” wastes your most valuable resource: time. Co-workers twiddle their thumbs. Engineers peruse the backlog. Maybe you go play ping-pong. It’s inefficient and wasteful. Enable your team to move forward by making the hard decisions, fast. You can always go back if you must — and you probably still saved time.
Part of your job is to make the least bad decision.
Consider that you work with smart people that make smart decisions as often as they can. If they can’t decide, they will come to you to do so. This means you will be presented with only the toughest decisions. You may only have 2 bad options and will have to choose the “least-bad” one. Accept that it’s better to decide, move on and learn than to debate endlessly burn out on it.
What is the one thing you need your user to do here? Can they do it?
Born of “feature ranking” exercises, I find myself saying this often. When I look at new flows, designs or features I try to pinpoint the “one thing.” If I can’t instantly identify it, or worse yet I mis-identify it, then it’s not good enough and we have to keep pushing and polishing.
Communicate. Communicate. Communicate.
This one should be obvious, but can be so hard to execute. PMs are constantly interacting across the org. making it easy to forget that you have a broader, fuller picture of the problem than anyone else. You must fill in everyone else. Be concise, be clear, be firm and be right. Follow up and follow through. Take notes and share them with everyone. Listen first and then ask questions to clarify.
Be responsible for results (value), not features (Marty Cagan)
I love the focus on value creation over feature creation. Rather than thinking, “this is the best feature I’ve ever built,” instead think “This is the move value I’ve ever created for my users!” Reframe your thinking in terms of value and you will build smarter, leaner products that users love.
If you don’t understand, speak up.
I have sat in too many meetings chalk-full of obtuse acronyms, technical jargon and over my head concepts. One day, early in my career, I just raised my hand and stopped the conversation by asking, “I’m sorry, but I don’t understand something. What does XYZ mean?” After the meeting, to my surprise, several people came up and thanked me for asking that simple question. I realized then that if I didn’t understand something, it was likely that other people didn’t understand either. Maybe too shy, or felt too junior to speak up. From then on I took it as my responsibility as a PM, and a communicator, to always ask for clarification, explanation or background on important and confusing concepts. Even if I thought that I may look stupid for doing so. This process has not failed me and it pleases me to help others by simply asking the question “what does that mean?”