The product manager I'm trying to become

A climbing-gym checkout looks like a simple fix. Follow the evidence to see what product management asks of us before, during and after launch.

A newcomer holding rental climbing shoes studies several routes across a sunlit indoor bouldering wall.

I’ve been a product manager for a few months, after seven years as a business analyst. They’re different crafts, and I’m trying to be honest about what carries across and what I need to learn from scratch. Even in that short time, I’ve collected plenty of advice, and I’m nowhere near pretending I’ve mastered any of it.

I keep hearing that we’re meant to stay close to customers while understanding what the business needs. We should have a point of view and leave room for the team to make it better. We should be strategic enough to know where we’re going and detailed enough to help get there. Somehow, we also have to admit what we don’t know and still give everyone a clear enough choice to move.

I can understand each piece on its own. A few months in, making sense of product management has meant working out why they all belong to the same job. The best answer I have so far is that product management helps us spend our effort on a worthwhile problem and learn whether our answer created anything useful. Everything in between helps us get less wrong.

The checkout looks guilty

Say we help run a climbing gym. The gym holds intro sessions for people who have never climbed before, and we can see plenty of people start a booking and leave before paying. Someone suggests simplifying the checkout. It’s a sensible idea, and there is even a graph that seems to back it up.

We could tidy the form, remove a step and ship the improvement. We could also do all of that without learning why people left.

The requirement to wear climbing shoes, or the cost of hiring them, might only become clear later than they expected. The session times may not work. Someone could love the idea of climbing and still feel nervous about walking into a room where everyone else seems stronger or more experienced. They may be stuck between an intro session, a casual pass and a membership, or checking the price before asking a friend to come.

The graph can’t tell those stories apart because it only tells us that people leave.

What we can see People leave before booking One observation can support several explanations.
Possible explanation Price surprise Check questions about whether shoes are required and where the hire cost first appears.
Possible explanation The times don't suit Compare the times people view with the ones they can attend.
Possible explanation First-visit nerves Listen to what new climbers expected before they reached checkout.
Possible explanation A tracking fault Inspect the event trail before changing the experience.
The drop-off stays the same. Each explanation asks for different evidence and could lead to a different change.

Before we touch the checkout, we need to understand the drop-off a little better. Who is leaving? What were they trying to do? What got in the way? What would become better for them and for the gym if we helped?

“People leave checkout” is an observation. “People who are curious about climbing can’t work out which first visit is meant for them” is one possible explanation. “People understand the options and get scared before paying” is another. We can investigate either of those. A simpler checkout doesn’t tell us which problem we’re trying to solve.

I recognise the instinct to help by jumping straight to the answer. I’ve written before about how much work one good pause can save. Product work seems to ask for that pause again and again, especially when the proposed answer arrives in such a reasonable shape that nobody thinks to question it.

We can take that habit too far. If a button says something confusing and changing it is cheap, reversible and unlikely to hurt anyone, we can fix it. We don’t need six weeks of interviews to prove it. Some work also has to happen for safety or legal reasons, so the choice is about how to do it well instead of whether to do it at all. The amount we learn should fit how uncertain we are and what happens if we’re wrong.

The price theory lasts about ten minutes

Our first theory is that people discover the full cost too late. Once we make that belief clear enough to challenge, it becomes a hypothesis: if we explain that climbing shoes are required and show the hire cost before checkout, we expect more new visitors to book and fewer questions about what they need to bring or pay. That might sound formal, but it makes our thinking visible: what we think is happening, what we might change and what we’d expect to see if we’re right.

Because the belief is now out in the open, we have somewhere to begin before rebuilding anything. We can read recent questions about climbing shoes, check where people leave the flow, show a rough version with clearer pricing to a few newcomers and make sure the drop-off isn’t a tracking fault.

When we speak with someone who nearly booked, they tell us the price wasn’t the issue. Every photo showed experienced climbers, they couldn’t tell what happened in an intro session and they were worried they’d be the only beginner in the room.

So our tidy checkout theory has lasted about ten minutes, and that’s fine because it changed before we changed the form. Perhaps the page needs to show what the first visit feels like. Perhaps an instructor can explain that nobody needs to arrive fit or know how to climb. Checkout may be completely innocent.

With price looking less convincing, the next hypothesis can follow what we learned. If people can picture the session and recognise themselves in it, more of them should book, and they should still feel comfortable enough to turn up.

We’ve let the evidence change our mind, which is exactly what the hypothesis was for. If we put “we believe” in front of a feature we’ve already promised and carry on exactly as planned, the hypothesis has become theatre. We can also run a tiny test on every decision until the work takes longer than the uncertainty deserves. We still have to judge which belief could make the idea fall apart, then what would make us less unsure about it.

Listening doesn’t make the choice for us

That conversation has changed our price theory, but it still tells us about one person’s experience. We haven’t suddenly understood everyone who considered the gym and left.

Another beginner may be fine with the photographs and unable to attend the available times. A parent booking for a teenager may care about supervision. A regular climber asking for a guest pass may want something else again. The people who feel confident enough to complain can be easier to hear than the people who leave without saying a word.

I’m beginning to hear “customer obsession” as a reminder to keep returning to people’s real behaviour and experiences before our own story becomes too comfortable. We might learn through conversations, observation, support questions, booking behaviour or a rough prototype. The method depends on what we’re trying to find out.

Those stories give the team something real to work with. Customers can tell us what they tried, where it became difficult and what happened next, while the people shaping the product still have to understand the wider problem and come up with something that works.

The stories become more useful when they leave the product manager’s notebook. If an instructor hears the conversation, they may recognise a fear they deal with every week. A designer may spot that the page assumes knowledge a new climber doesn’t have. An engineer may notice that the drop-off event can’t be trusted. They can do much more with the context than they can with a summary and a list of requirements.

Even after hearing all of that, we still have to choose what to do. By now the gym could explain the intro session better, add more useful times, improve reminders, make casual visits clearer or simplify checkout anyway. All of those may help, and we probably can’t give all of them the same attention at once.

Choosing among them also means thinking about what works for the gym. If people feel prepared, enjoy the session and want to climb again, the first visit has been useful on both sides. A burst of bookings followed by cancellations, refund questions and half-empty sessions only looks good for a little while.

Now “business value” has something concrete behind it. Here it could mean more intro sessions that people attend, enough demand to run them well and more newcomers choosing to climb again. That outcome still has to fit the gym’s limits: a certain number of instructors, a cost for each session and a promise it can make honestly to a nervous beginner.

With a concrete outcome, strategy starts to feel less mysterious. If the gym wants to be the easiest place nearby for a complete beginner to try climbing, reducing the uncertainty before a first visit deserves attention. A useful idea for regular climbers can remain useful and still wait.

A prioritisation framework can help us make that choice with our eyes open by reminding us to think about reach, effort, confidence or risk. It can’t decide what kind of gym we’re trying to build, and decimal points can’t turn guesses into facts. We still owe each other a plain explanation of why this problem, for these people, now, and what we’re leaving alone so we can give it a proper chance.

Then the rest of the team gets hold of it

Suppose we choose to make the first visit easier to understand. That choice gives the team a direction, and the idea will change as soon as the people who know different parts of the gym start working on it.

The instructor knows which fears disappear during the first ten minutes. The person at the front desk knows why people arrive confused and which questions keep coming back. A designer can see where the page asks newcomers to decode climbing language. An engineer knows which journey data can be trusted and which apparently small change creates a lot of ongoing work. Whoever looks after the finances knows how many lightly booked sessions the gym can sustain.

If we only bring those people in after the answer and deadline are fixed, most of that judgement arrives too late. Giving people room to solve the problem only works when there is still room for them to change the answer.

That room also depends on the relationships we’ve built before we need somebody to disagree. An instructor is more likely to say the page has missed the point when their earlier concerns haven’t disappeared into a notebook. The front desk is more likely to keep sharing the questions they hear when we come back and explain what happened to the last thing they told us. An engineer can question the tracking more openly when the conversation won’t turn into a search for who got it wrong.

The part I’m trying to learn is how to build enough trust that awkward news arrives early, ask useful questions, notice when a trade-off has moved and keep the original problem from disappearing while the answer changes. That also means explaining why a choice was made, giving people credit when their judgement improves it and coming back to say when we got something wrong.

As the answer takes shape, product work carries on through the parts that can look less exciting from a distance: deciding scope, handling edge cases, planning the release, helping people support it and making sure newcomers can find it. The beginner-friendly page won’t feel very friendly if it says shoe hire is available, then the confirmation email tells everyone to bring their own.

I don’t want to treat strategy as the clever part and delivery as the admin that follows. Execution is full of decisions that can strengthen the answer or hollow it out. It is also where we get the repetitions that can turn into experience when we pay attention.

Some product managers inherit more of the direction and spend more of their time helping a team deliver it. Other teams spread the work across several roles instead of placing it all with one product manager. Business analysis, product ownership and product management are different crafts, although the shape of each job still changes between organisations. Product Management keeps showing up in how people clarify the need, expose a risky assumption, bring in customer context, improve the answer and learn after release.

The bookings go up. So do cancellations.

The gym eventually updates the page. It shows people at their first session, explains exactly what happens and makes the welcome feel real. More people book, and then cancellations rise.

That result gives us two easy stories. We can say the page worked because bookings went up, or that it failed because cancellations did too. Both answers arrive before we’ve understood what happened.

Perhaps the page convinced people who were always likely to change their minds. Perhaps the reminders are poor. The session times may still be awkward, so people book hopefully and cancel later. A seasonal rush could have lifted bookings whether we changed the page or not.

The uncertainty is why shipping sits closer to the middle of this story than the end. It has given us better evidence and more thinking to do. We need to see whether the experience improved, who benefited, who picked up extra work and how confident we are that our change caused what we’re seeing.

What we find might support our hypothesis, send us back to the problem or tell us that the opportunity is smaller than we thought. It should change the next decision, perhaps by sending us towards the reminders, the people who cancelled or the session times, or by showing us that the gym should spend its time somewhere else.

A dashboard nobody revisits leaves that next choice untouched, and so does a thoughtful retrospective that never changes the next piece of work. We have to carry what we learned into another decision.

When the process changes nothing

By this point, our gym has done almost every bit of Product Management we’re told to do, and it still could have protected the checkout idea from the beginning.

We can interview customers and keep only the quotes that support checkout. We can write a hypothesis after the feature has been promised. We can give somebody’s preference a prioritisation score with two decimal places. We can cut the answer until it meets the date and barely touches the problem, then celebrate whichever number moved after launch.

This can happen in teams full of thoughtful people. Organisations may reward visible output, speed and certainty while customer access stays difficult and teams inherit commitments or measures they didn’t choose. The craft has to survive in those conditions, because very few of us work in teams that control every choice, have unlimited time and can easily reach everyone they need.

The idea already belongs to someone

Even in the gym we’ve been imagining, the checkout idea can already belong to someone before we understand the problem. By the time we speak with the nervous beginner, the owner has told the front-desk team that an easier checkout is coming, somebody has spent days preparing the new checkout pages and an Instagram post about simpler bookings is already sitting in drafts. Changing direction now means asking several people to unwind work they believe in, while the person who pushed for checkout has put a little bit of their reputation behind it.

That first conversation isn’t enough to sweep all of that aside, but it gives us a reason to keep investigating. We ask the instructors how often they calm the same nerves, compare that with the questions reaching the front desk and look at whether people who book actually attend and come back. That brings us back to what the gym wants in the first place: more beginners trying climbing and wanting to continue.

The owner still wants the checkout work to go ahead. We say plainly that we think it leaves the bigger problem untouched, then use what we’ve learned to reshape the plan: keep the useful checkout clean-up while making the new page show people what their first session will feel like. The person who backed checkout has room to improve the idea without the new evidence becoming a public verdict on their judgement.

We write down what everyone expects the combined change to achieve and agree on when we’ll look at bookings, cancellations and repeat visits again. The trust built across the gym gives us room to challenge the choice, while those expectations give us somewhere concrete to return when the results arrive.

Across this one small gym problem, each part of the craft changes what comes next. Speaking with newcomers moves us away from price and checkout. A clear hypothesis makes the risky belief easier to challenge. The instructor’s view brings the first ten minutes into the page. More bookings encourage us, while more cancellations stop us from declaring victory. The trust built while working through those choices helps the uncomfortable evidence reach the people who can act on it, even when earlier promises make changing direction harder.

Research, strategy, collaboration and measurement belong together because each can change the problem, the answer or the next choice, while the relationships around the work determine whether people can raise difficult evidence, challenge a decision and act on what they learn. If the research, choices, conversations and results leave the original idea untouched, we’re mostly using the rituals to make it look more considered.

A few months in

I expect my answer to keep moving because a few months is barely enough time to learn the language of a craft, let alone settle what it asks of us.

For now, I want to get better at finding the question worth answering before I become attached to an answer. I want to form a view while there is still uncertainty, then make it easy for evidence and other people’s expertise to improve that view. I want to understand the organisation without letting “the business” become a vague reason that ends the conversation.

I also want to stay for the less exciting parts: the scope change, the awkward edge case, the launch and the first result that can be read three different ways. That seems to be where all the good advice has to become judgement.

If I can help a team get less wrong about the problem, make a thoughtful choice and come back to find out what happened, I’ll be learning the job I hoped Product Management would be. A few months in, that gives me plenty to work on.