[ad_1]
Did I say “new”? I think I meant to say “most”.
Let’s get this out of the way first: product management is basically an impossible job. No, seriously, it is. The sheer amount of things or people or processes that we need to wrangle in order to do our job effectively is frankly a bit insane, and none of us, no matter how practiced and seasoned, can claim a “perfect” launch or meeting or deck.
So when I discuss mistakes new PMs often make, please understand that while these may be most common in new PMs, experienced PMs make them all the time as well.
Ok, so let’s dive in. These are many of the mistakes I and many of my peers made when starting out, and if I’m being totally honest, I still struggle with a lot of these today! Let’s get after it.
This one is especially pervasive within consumer product companies, where the product managers also use the product or service in their personal life, and man is this one a hard one to shake. Yes, it is true, as a user of your company’s app or service, you do have valid insights into issues and opportunities.
I don’t want to rob you and your team of the joys of dogfooding your product and fixing or optimizing things you discover…but…you are a unique human being, and there are many other unique human beings that use your product, that when viewed more holistically fall into types of users (personas) that you can and should be more broadly building solutions for.
Again…this opportunity you have found within your product is likely an opportunity that other customers also resonate with, BUT the name of the game in product management is prioritization, and while you could solve for this opportunity, what other opportunities are you simultaneously leaving behind? You might have solved for a problem 5% of your customer base experiences and left a 60% problem on the table. This will be a theme in this article, but don’t assume anything. Ask questions, talk with customers, review quantitative data and find ways to test your hypothesis.
At the end of the day one of the most important roles you have as a product manager is to build “shared understanding” amongst your spheres of influence (business stakeholders, designers, engineers, QA, etc). Here’s what this doesn’t mean: this doesn’t mean that you need to write more PRDs or Confluence Pages or Notion Docs.
It does mean that you need to have more conversations. It’s honestly this simple. Bring in design and dev early on. Share ideas, ask questions, listen a lot. When you are done having these conversations write down your assumptions and risks somewhere and reference them as you continue down the path of defining and building your solution.
If you want to learn about what I think is the single most effective way to build this shared understanding, read my article below on “User Story Mapping”. It’s the #1 process I think every product manager needs to be able to utilize.
Honestly this is just an extension of #2. The old way we worked as product managers, even back before we had the title of “product manager”, was to talk with the business or customer, go into a room and bang out a crazy detailed “Product Requirements Document”, hand it to a designer to design, and then have that handed to developers to develop.
Please. Don’t. Do. This.
Yes, as a PM it is your primary job to determine the right problems to solve and to understand business feasibility and viability around the proposed solution, but you need to have conversations with your designers and engineers as you put together the requirements.
These are people that are also touching the product or customers and they have really good ideas or thoughts or opinions. Use these early conversations to help shape your vision of the future and keep the open lines of communication open as you progress towards having a solution in customer’s hands.
It’s day one in the new gig and, as expected, you are SO excited. You meet the team, get access to your squad’s JIRA board, get an overview from your leader about the area of the product or customer journey they want you to focus on aaaaaaaand…what now?
Well, you don’t want to be lazy, or even worse be perceived as lazy, and so you jump right in. You’ve used products like this one before (see #1), and you see a previously prioritized list of stories and features, and so you pick one up that feels right, get with design and work furiously to produce “real value”. You were hired to ship features, no sit around and twiddle your thumbs, after all…right?
As a new (or experienced) PM getting started at a new company, this is one of the worst things you can do. There is nothing more destructive to a technology company than an un-informed product manager. The short version of what you should be doing is becoming an expert on your industry, business, product, team, and technology.
There is nothing more destructive to a technology company than an un-informed product manager.
This is such an important topic I wanted to dedicate an entire article to covering it. If you are starting out at a new company, I would highly recommend you give it a read — it’s a quick one.
Do you hate being wrong? I HATE it. It’s my least favorite thing, and I would bet you’re a little bit like me in this way. Here’s the rub: many of us dislike this feeling so much that we let it sneak its way into how we work in some pretty deceptive and destructive ways.
One of the most destructive ways this can show up is when we are asking teams, customers and the data itself to not test our idea, but rather to validate it as a good one. The difference here can be slight, but impactful. It can be as simple as your phrasing when interviewing customers. Look at these two questions and see if you can spot the difference:
- “Would you be interested in a “Favorites” button that made it easy to filter through our entire catalog to find the ones that you really loved?”
OR
2. “Today how do you finding items that you previously enjoyed? What pain points do you have with this process?”
In the first question, I have both the problem (trying to find items that I previously purchased and liked) and the solution (a favorites button) in mind, and I really want to hear the customer validate my idea so I can say to myself “a customer said they would like it, so therefore I can clear my conscious and go build it”. The second question is simply intended to dig further into the problem space to understand more about how this problem manifests in customers lives.
Seek to understand the customers problems on a deeper level, don’t get too attached to any one solution, and work to test your ideas as much as possible, looking for holes and ways they can fail. This will ultimately lead to a much better solution.
This picture 👆 perfectly describes my gut-reaction to considering issues or risks with one of my features/products. I want to bury my head in the sand, cover my ears, say “LALALALALA!” and pretend I didn’t just realize there’s a giant risk in my release, because I think deep down I believe that if I just push forward and DON’T think about these things, they won’t happen. Maybe you’re the same, or maybe I’m just a weirdo.
Regardless, reality obviously doesn’t work this way, and I cannot over-emphasize the importance of spending at least a little time thinking through how things can go wrong, up-front. Some product teams take this so far that they conduct what are called “pre-mortems”, a play on the term post-mortem”, a common practice of reviewing what went wrong after something launches.
A pre-mortem is nothing more than pretending that this feature or product has already launched and stuff did in fact go wrong. Maybe even very wrong. Then, as a cross functional team, you sit down and discuss what did go wrong, and what could have been done to avoid it. No matter what approach you take, put in the time up front to document these so you can move forward with eyes wide open.
Pretty soon I am going to be writing an entire article about this one word — this is how impactful I think the question “why?” is for product managers. It’s one of our super powers as a PM, and so often we forget to use it. There are many ways to use this question, but the most fundamental is to get to the “base desire” that underpins customer and stakeholder requests.
When a customer or stakeholder explains what they want out of your product, ask “Why?” a few times, enough until you get to the core desire behind their request (this is what people are talking about if they reference “The 5 Why’s” — the idea is if you ask “why?” five times, you will always get to this core desire).
Let’s use this lens to look at the classic Henry Ford quote, “If I had asked people want they wanted, they would have said a a faster horse.” This is true, of course. But if he had asked “why do you want a faster horse”, they might have said “because we want to be able to get from point A to point B faster”. There we go. Only had to ask “why?” once, and now we see the deeper desire that needs a solution.
Here’s a fact that alludes a lot of us, especially when we are first getting started in product management. Product Management is a craft, which is to say it is a definable type of work with best practices and the ability to get better and better (or worse and worse). Not only this, but there are a lot of people, just like me, who dedicate LOTS of time writing, teaching, coaching and evangelizing the craft of Product Management.
Many of these people (also like me!) additionally develop processes, practices and ways of working that are designed to help you scale your efforts and more quickly tackle whatever it is you are trying to tackle. This could be discovery, validation, testing, business modeling, etc. The callout here is to use your old pal Google, and look for other people that have already solved for the thing you are trying to solve for, and use their methods to start with.
Sure, you can grow and morph these to suit your needs, and eventually you may generate an entirely new way of working, but for now, when you are starting off, try and stand on the shoulders of those that come before you. This will make you a whole heck of a lot better at your job that your peers that aren’t doing this.
Product Management is a craft, which is to say it is a defined type of working with best practices and the ability to get better and better (or worse and worse).
In the meantime, check out the linked article below to get started with my product development framework, which has helped many new PMs get their footing when trying to understand how in the world they are supposed to take something from “idea” to “shipped solution that customers love”.
“MVP” stands for “Minimally Viable Product”. The concept is solid, and lies at the very heart of agile development. The notion is to start with a version of your final product that is simple enough that it solves your customer’s core problem without adding any additional complexity that isn’t absolutely needed at the offset. It should be as simple as possible, but still something that users enjoy and want to keep coming back to, and such that you can continue to enhance it as you learn from customers and look to add incrementally more value with each release.
Here’s the problem, though: it is actually pretty dang hard to determine what your product’s MVP actually is. To do this effectively you need to 1) talk with a LOT of customers, 2) go through practices like User Story Mapping to understand how customers would narratively flow through your product to solve their problems and 3) spend time with your business to make sure that the MVP meets the business or financial needs of the company. This is work. You will not arrive at your MVP after a few meetings. You won’t figure it out in a vacuum. Spend the time up front, because once you release, you often can’t get those customers back.
Let’s end with a fun one. Believe it or not, celebrating wins and generally inspiring your team is a huge part of your job. Like, a really huge part. As it is primarily your job to introduce and inform on the customer problems or opportunities your design or development team takes on, it is also your job to let the team(s) know how the release(s) went, what learnings were gleaned, and who we should be throwing confetti and champagne at!
Too many developers (and designers for that matter) build in a vacuum. They receive their intake, do the work, push it to production, and move onto the next task. A few months go by and they think “I wonder how that feature ended up doing”? This adds friction and can lead to lower team morale, reduced innovation, and ultimately greater attrition.
As human beings we desire to be bought in to a company and team’s vision and mission, to make an impact on the world around us and to be praised for work well done, and without these full loops of information or celebration, teams just aren’t as effective or resilient as they could be.
As always, I really hope this was helpful. Starting out in Product Management is insanely challenging, and one of my missions as a coach, writer and educator is to help new PMs not only stay above water, but excel in their work.
Put any question or comments in the article as I love reading and responding to them, and once more let me direct all you new PMs to the below article, as I wrote it specifically to help you land on your feet. 👇
[ad_2]
Source link
