Target Your Roadmap — Continued

Success breeds success. The roadmap that I built for the dev team was good for purpose, so why not repurpose it for the sales team? Also, it took me weeks to get the roadmap into the state it was and I was not about to spend that much time on another version of the roadmap. The one I had ready would just have to do.

Sales people are not developers, and they know it. They are hard negotiators that don’t need to be right to win an argument. Developers care about logic; sales people care about getting to yes. The handicap you face as a product manager is that you spend most of your time with the former and not enough with the latter. The “yes” you get at is not the one you were aiming at. As far as sales people are concerned, that’s not a bug; it’s a feature.

“So, Marco, where’s that roadmap you promised us? We really need it; our customers will not buy into a platform that does not have the next two years of releases plotted out.”

With your blessing, I will skip over a lot of details. No recount of the discussions leading up to this request, no elaboration of arguments in favour or against; just, as they say, the facts.

I looked at my calendar and assessed the benefits of creating a sales roadmap: improve my relationship with the sales team, deepen their understanding of the product, strengthen their ability to engage with their prospects on the problems they are trying to solve instead of just on the features we deliver. Then, the counterargument: it takes more effort.

Having so much to do and so little time, I took to Slack and arranged a roadmap meeting with our sales people. They were excited to hear the product team was ready to share the product roadmap with them. Boy, did I underestimate the shitstorm that was about to break out.

As I stood before my audience, it hit me. “That reservation option will help me close the deal I am negotiating, cool!” (Yes, and do keep in mind the team hasn’t started working on it yet) “Oh man, my prospect is going to love the simplified onboarding registration process!” (Please, no, we are still in Discovery for that feature…) “I’ll call my client right after this meeting; I think I can upsell the premium SAP connector straight away” (That’s in phase 3! We are in phase 2 now, when we intend to roll out the basic version).

Firefighting, herding cats, whack a mole — choose your metaphor; it does not come close to what I had unleashed. I was forced to churn out a dedicated sales roadmap in which I highlighted the items the team was working on at the moment, the items the sales team had requested and were under discovery, and future themes and problem areas that we intended to address. All while mitigating the unrealistic expectations I had set as a result of my laziness effort optimisation.

With time, I managed to repair the loss of trust through delivering on our commitments, careful communication and, yes, a dedicated sales roadmap. Please don’t repeat my failed experiment and respect your sales colleagues for what they are: specialised deal makers that jump on opportunities you’d never dream of. They deserve your commitment.

Target Your Roadmap

I remember being lazy and regretting it instantly. The roadmap I had created so successfully for our developers proved decidedly unsuccessful with our sales team.

What had started out as an opportunistic cost-benefit analysis of the effort required to design a dedicated roadmap for our sales people, ended up as a cruel Product Management 101 lesson: don't just show any roadmap to any stakeholder. And you don't just walk away from that mistake either.

Allow me to elaborate.

"Hey Marco, you know that we need more than just the JIRA backlog, don't you? Here, check out these three epics; clearly, they build up to something bigger, but where can we find the vision for that?"

The thing I love about my developers is how hopelessly tactless they are. The thing I hate about my developers is how hopelessly tactless they are. Mostly, it depends on my mood which feeling prevails. The tactlessness remains.

So it happened that I consolidated all my knowledge into one document: vision statement, target users, user goals, business goals, technical dependencies, product themes, features and prioritisation. Oh, and target quarters, to gamify the planning exercise a bit; planning is no fun without antagonising your developers, so adding target quarters to release features in makes for energising planning sessions: "Hey Marco, you can't just go write arbitrary dates without consulting the team!" That.

Anyway, after several iterations, the team did get used to my way of building roadmaps; it served their purpose as it helped them understand how they contribute to delivering value to the user, the customer and the business. In the process, that allowed them better to architect their designs, as well as anticipate dependencies and technical debt. Douze points from the developer team.

Word reached me that the sales team were dissatisfied about their lack of insight into future development of the product. How were they going to sell anything to the customer if they couldn't entice them with what was upcoming? That's just elementary, so why won't the Product Manager do it already?

The "it" here, you understand, is the roadmap. Tomorrow, I'll talk about how I messed that up. And how I had to make amends.

Hope Of Deliverance

You know the drill, don’t you? “Hi, here’s my product requirement. By yesterday, no validation, no iteration.”

Turn around, do not pass UX, and ask your Development team for their effort estimate. You’re unable to explain why this requirement makes sense for the product. T-shirt sizing, Large, three months.

— Can we make it in time for the grand opening in two months?

Further negotiations with the team, who were already driving blind in the first round of estimates. Now, they are cutting corners on an imaginary implementation plan that hasn’t even been validated yet. T-shirt sizing, remember?

If you wonder why the Business believe the estimates, believe me, they don’t. The Plan lives a life of its own. It eats dates for breakfast — customer value, not so much. You destine your Dev team to a life of Delivery. You are not a Product Manager; you are a Delivery Manager.

If you were a Product Manager, you’d have listened carefully to your stakeholder and made them aware of your Product Strategy, suggested alternatives, shown ongoing validation rounds — in other words, you’d have pulled your stakeholder into the Product Development flow.

Besides inevitably disappointing your stakeholder when the deadline makes that whooshing sound as it goes by, you relegate your Development team to a role of mindless implementers and your UX Designer to that of UI doodler.

Perhaps you are left with no choice as your organisation expects you to work this way. That’s legitimate; we all need to protect our financial security. However, do realise that you and your Product team are on a repeat collision course with reality.

Your outcomes will suck, your Developers will leave, and your UX Designer will start avoiding your messages. Not a place you want to be.

I’ve got one word for you: Discovery. I’ll find the time later to write more about this. Meanwhile, know there’s hope of deliverance.

Imposter Syndrome

If a company hires you as a Product Manager, are you the product expert? Almost by definition, no; you’re a new hire and an uphill struggle awaits you.

“Hey Chris, meet Marco, our new Product Manager. He’s joining our team and is responsible for our Product Roadmap.”

There you are, set up to disappoint your colleagues from day one.  Aren’t you looking forward to your new job?

I’ve been through my share of onboarding periods as a Product Manager. High expectations, urgent needs and little context: no pressure, man, we count on you to make this work. Right, thanks boss.

I’m pretty confident that I surprise exactly no one when I say that a new Product Manager is not the product expert. At best, they are a Product Management expert.

So what do I do in those circumstances? Basic Product Management 101: manage the expectations of my stakeholders, inexorably. Communicate my 90-day plan, on repeat, and get my colleagues’ feedback, get them to tell it to me in their own words, suggest ways of working together in this mode, and so on.

It will involve steps like learning about the product, the strategy, the organisation. You will want to underline your desire to learn from your colleagues, understand their roles and objectives, their expectations around the Product organisation. You are a sponge.

Conspicuously absent in this list of what to do is anything to do with presenting yourself as the go-to product expert. On the contrary, make your curiosity your hallmark: who knows best? Is it the developers? User experience, the business stakeholders? Do we have access to the customer, the user? Shout it from the rooftops: I am a product novice, I am here to learn!

The Imposter Syndrome is hard enough to deal with as you battle your own insecurity. Don’t provide the ammunition to those around you as you work your way up to true product proficiency.

You’ll see — you’ll get there.

They Live

You know the joke, right? A CFO and a CEO meet.

— What if we train them and they leave?
— What if we don’t and they stay?

The irony here, I hope you appreciate, is the “they”. Observe the mindset that emanates from this punch line: accept the premise and turn it inside out. Funny, radical and… inside the box. I’ll try and explain.

The two executives talk about their employees, they decide over them. It occurs to neither of them that it would be good to involve them as the intelligent actors that they are. They live!

Alright, I admit, I killed the joke. Still, as Head of Product leading a team of Product Managers and UX Designers, I struggle with similar situations. Check out Cagan in his excellent book Empowered: the single most important responsibility of a Product Lead is the professional development of your people.

Involving your people does not absolve you from leading the way. But leadership is emphatically not deciding over them without understanding their priorities. And I know of no better way of learning their priorities than giving them a seat at the table.

Therein lies the rub. What if your people don’t sense their priorities? I mean, in an ideal world of intelligent actors, every one of your team members have a clear understanding of where they want to be and what they need to do to get there.

In my weekly one-on-ones, I make it a point to go over their development needs. We each share our observations about the improvement that would deliver the highest marginal value as a Product Manager or UX Designer. Then, on a monthly basis, we evaluate their progress and assess the next priority.

One or two of them are catching on. They actively question where they want to be a year from now and form an opinion as to what they need to improve. The rest? Tumbleweed, no involvement.

I wonder, what am I missing? If you water a plant, but the plant falters, there’s something else you’re doing wrong. The plant, it has an innate urge to thrive — no need to stimulate that. Instead, it needs more shadow. More sunlight. Less draft. A more fertile soil. Or less, but it’s up to you to find out.

Involve your people, fail and learn. In turn, they will hopefully grow.

Product Managers Make Lousy Lovers

It had to be said: Product Managers are needy. If you’re in a romantic relationship with one, I don’t envy you (hey love, looking at you!). Do you think I’m kidding? Bear with me, and you’ll come around: Product Managers make lousy lovers.

Sitting in our open office in lovely Amsterdam, looking over the canals, I pondered whether mobile users differ significantly from desktop users. Smartphones had just started to make a splash in our visitor stats. Our site clearly wasn’t mobile friendly. Hell, it wasn't even mobile aware; were we failing to address the needs of our mobile users?

A few weeks earlier, I’d sat at a desk with our mobile dev team and suggested we owed it to our mobile users to provide the exact desktop experience in a mobile format. Simply put, my approach to the mobile experience was as superficial as it was inane. I had not validated the use case job to be done our mobile users were expecting from us.

Did the team object? Sure. Did they not push back? Hell, yes. But, you see, they are Developers. They are User Experience. They approach the question from a narrow point of view. Leave it to the Product Manager to take the holistic stance. Trust me; I know what I’m doing.

And yet, here I was: were we failing to address the needs of our mobile users? Boats sailed the canals slowly, lazily. It was a chilly, Dutch Spring afternoon, but we’d opened the window and the sound of traffic passed through. I channeled myself onto the boat two hundred meters further along.

“Sander! Have we even analysed our mobile traffic? Do we have any hypothesis as to why they come and visit our site?” I knew the answer. Sander is an incredible UX Designer; paired with a great Product Manager, he’d make a dent in the Universe. I’d failed him.

Clearly, we needed to validate our assumptions about why people accessed our site on their smartphone. Observe them, ask them. Did we address your issue? Are we delivering value? And if we aren’t, is someone else doing a better job at it?

If you don’t validate your assumptions, you are driving blind. Observe, ask, double check. Are you delivering customer value? You’re guaranteed to find blind spots you are not aware of now. Address those and your customers will love you for it.

It’s like asking your partner if they love you, every day. Unlike with customers though, you will exasperate your lover. You will end up sleeping alone.

Product Management By Any Other Name

Hi, I’m Head of Product. Long-time Product Manager, first-time blogger.

For my second job, they hired me to fill the role of Marketing Manager. I had no experience in marketing. This being 1999, there were no social networks and no viral posts. I figured I needed data before anything, so I set out inquiring what, to whom, where and when we sell. My boss handed me our product assortment: vas-y, Marco, dis nous comment mieux communiquer chez nos clients!

It turns out, I was lousy at marketing — still am. Instead, I took the assortment and went around the company asking: how well are we selling each of our products? When do people buy them? Do we know who buys them? Most of the time, the answer I got was, “Je ne sais pas”. Only the numbers guys were able to tell me where to find the sales figures, by the minute, real-time even. That was a start.

Soon, I learned that the colleagues using those numbers most were our purchasers. They used them as triggers for purchase orders: keep a tag on how much we ordered, monitor ongoing sales and as we reach a certain threshold, place another order. Simple.

If only; even in 1999, I was surprised to learn that they were doing this mostly on paper. Every morning, they would print out a one meter stack of paper, mark the pages that interested them and toss away the rest. Then, they would input sales figures, line item by line item, into their Excel file. Once they’d finished this tedious ritual, they’d know cumulative sales for each line item and mark those products that needed reordering.

Wait! Marco, I thought this was a Product Management blog. Also, weren’t you supposed to work as a Marketing Manager? What’s up with that?

Glad you asked: finding problems worth solving, that’s what’s up with that. I am no engineer, so don’t look at me for solving your problem. I am a Product Manager, so I’ll help you describe your problem in ways that make it worthwhile to solve. The fact that I was a Marketing Manager at the time is neither here nor there. As is the fact that I then proceeded iteratively to solve the problem as a one-man team until I got the budget to hire a capable Marketing Executive developer who helped me roll out a solution that enabled our entire Purchasing division to check their SKU levels in a matter of minutes.

If you want to know more, buy me a beer. In the mean time, happy problem finding.