Stakeholders want feature parity and shorter deadlines. How to handle them?

Becoming a product manager FAQs
,
1

I am a Product Manager for the next generation software to decommission an old product. Now the stakeholders- mainly sales and marketing - are jumping up and down and they escalate because they never listened to the fact that I told them we have a v1 and then a v2 and lots of scalability issues. They don’t really understand Product and they keep pushing of course as they want to sell more licenses.

My two issues are:

  • Priority: I told my management that if we want to prioritize this huge development we would need to deprioritize or add resources.
  • Feature parity: I am not going to just copy and paste a 10-year-old software without clearly seeing the value or getting usage data.

Now I am getting more and more as the bad cop in that company, and I think I am also just not yet good enough at stakeholder management. What can I do? Get detailed estimation for all of their features wishes? Create my own roadmap and vision? Get signed off commitments? Other idea?

10 Likes
2

This is a super tough situation. Some companies just can’t handle how expensive software is. They want it now and want it to have no impact on the roadmap.

The only thing I would do, which you may well have already tried, is working through a few key use cases, getting engineering across it and getting some high confidence estimates. Or walking through the effort of recent deliverables. Or getting estimates for a full rebuild.

I’d then focus on getting some people across how big things truly are and convince them that a full rebuild just doesn’t make sense. If you can get a base of supporters on side you can have alignment cascade up or down from there.

But I won’t pretend that it’s easy or even possible, it depends.

10 Likes
3

I just inherited a product in this same situation, spent the last 4 yrs building net new and it’s still not quite ready for prime time. Meanwhile the old solution hasn’t been updated in several years so it’s way behind competitors. Everyone’s out of patience, not been a fun for a few months.

It sounds like your instincts are good, but you also have to face reality that company can’t take a couple years off while solution is rebuilt. How long is the v2 build estimated to take?

As another comment said, people outside of it day to day rarely understand how long it takes and how expensive it is to build software.

Is it your idea to rebuild, do you really have to rebuild or is there another path? You’re going to need massive buy-in from leadership across the company to do a full rebuild and lots of patience. All the way to the CEO really, or you’re in for a really challenging project.

9 Likes
4

@MarcoSilva, Thanks for the help. Let me clear: I don’t want a full rebuild but rather focus on the key use cases and then go out with a well working product for the main users and work from there. Unfortunately, many stakeholders don’t understand that concept and also don’t understand the complexity of software. But they tend to play their games as they believe by escalating, they would magically get all their features and get it faster.

8 Likes
5

Introduce them to ATERN and the ‘triangle’. Whenever these outrageous demands come, even though we don’t use DSDM, I rely on ‘there are three points, cost, time and scope. Two of the points are always fixed. Which should we fix for this project?’. i.e., do you want to flex scope to hit a deadline, or move the deadline and keep scope, or throw more money at this (and incur the wrath of the Mythical Man Month)?

8 Likes
6

@AmyWalkre, I did that, and they usually say: So how much money do you need? Can you get some contractors speeding up things.

I personally don’t even want to down that rabbit hole as I know that is a endless route of me being to blame anyway.

7 Likes
7

Do they understand that adding more people makes it more complex for the engineering manager and not easier or faster?

7 Likes
8

@ShiyaoLiu, well, that’s better than my precious boss who was unwilling to compromise on cost, time, scope and said that the number one skill of a PM is to learn to push the engineers harder :frowning:

6 Likes
9

Been in this sink hole. What I did (two diff startups same result - one was complete rebuild) was get the key stakeholders included in the build journey so they “get/understand” how software is built iteratively - effectively becoming my champions/defenders. How I did this: got them to agree overall scope and roughly what was gonna come each iteration (yep scope was tough) but crucially I got them to come to our show&tell i.e demos to see what was ready for use practically based on each iteration scope and where we also covered briefly other items/prod issues delivered in that same iteration.

The number of times they said things like “wow I didn’t know it took that long to do that or hmm and you guys dealt with that prod issue too; amazing etc.” stunned me too in the 1st startup.

They just have no idea why things take the time it takes; how other issues can affect us, and I had to bring them - school them - in my world. It shocked me that some thought it should be easy for dev team to multitask i.e., work on X and also on Y same time cause that’s how it’s kind of done in their world.

I initially tried some of the stuff posted by others but no change, so I went the route described. May not work for you.

5 Likes
10

@RichardsonEva, Thanks a lot for the thorough response. I will try to do this. One stakeholder who is especially difficult never shows up on meetings but keeps just moaning/escalating. Any advice to manage these:)?

And regarding iterative approach: That is key, I agree but I am trying to teach them: Do you have like a textbook example you can recommend?

Thanks

5 Likes
11

Hone in on your “influencing” skills. Comes/earned from battle scars. Ignoring for a MO the challenging stakeholder - of the other stakeholder(s) that come to meetings is there one (or two) that you have good rapport with you could use tacitly to get the challenging stakeholder onside. Several ways to do this but as a 1st pass - your champion/defenders getting her/him coming to meetings, booking follow up meetings with said stakeholder but including these champion/defenders in the meeting too etc. Important to determine if the onside and the challenging stakeholders have rapport again easy to determine by the way they’d talk about said stakeholder when her/him not present for example.

On iterative approach: If you are well versed in iterative & incremental development, including scoping, then use that knowledge to tailor what you want them to learn. There are quite a few blogs on this you can search on. Yeah, books exist too but blogs get straight to the core. Don’t want to name any but a good search will throw a few up you can read.

5 Likes
12

In the same situation, took over a product doing this, and the previous PM never really pushed back on anything. Now I’m the bad guy for actually wanting to put thought and data into the product that is supposed to be the future of the company.

4 Likes
13

I think you should probably do a scenario planning/implications presentation /cost benefit analysis for them.

Present it to all stakeholders,

Let everyone know if we do A, this is most likely what will happen… (try to itemize how engineering, design etc. would be affected as well etc.).

If we do B etc.

When you paint the pros and cons of all options, let everyone vote, and let them know if there’s a stalemate, you have veto and they’d have to go your way.

Bring in management and all for this.

That way, if they choose what you said they should not and things you predict start happening, you have de-risked yourself and they will listen to you later, if you still decide to be there anyway.

Regarding deadline (if you’re not using scrum already, use it), let them know the best you can do is estimate and estimates are usually shit into you can gauge the team’s velocity after like 2-3 sprints before you can know how much deadlines can be reduced and what not.

3 Likes
14

Regarding estimates this is the single most thing I always hated: Be it planning poker or t-shirt size of big-small batch per increments. I just never got it working right. Do you have a good recommendation?

3 Likes
15

@YuriRoman, I share the sentiment!

Though I don’t have much experience yet but in my book, a lot of things go into this.

Getting the estimates is just like a data point your prioritization and velocity measurement.

You team has to understand why you’re getting the estimate, if they don’t get it… they’d just do the exercise coz you say so or think you know what you’re doing.

For me, it’s to be able to realistically gauge our speed and execution rate, and to know how to set realistic targets for ourselves and to communicate it clearly with management to prevent un-necessary pressure.

Step 1- Make them understand why the estimation exercise is important.

Planning Poker, Shirt size and what not are all effective ways to estimate really, it’s how you use it that matters, I’ll suggest planning poker though, that way you can have actual points to use for your story points which you can plot against time to measure velocity.

So after say two or three sprints, you can know how long it takes your team to perform tasks that are certain points, over time you’d be able to get a feel though.

It’s all organization based really.

Step 2- Measure and record the performance after a few sprints and after which you’d be able to get to a close enough range of estimation.

Step 3- Let everyone know they can do better and go faster, keep pushing till you know when the team has had enough and, you’d have to use your instincts here and also during sprint retrospectives, Godspeed!

Ps: I’ll suggest an audio book you can read, it was written by J.J Sutherland Scrum: The Art of doing twice the work in half the time.

It’s not technical but it has the foundational principles of how scrum was developed and all.

3 Likes
16

@RohitKumar, Have you ever seen this working? I know the textbook and been in countless trainings, but after seeing now the 4th company not able to do use it, I doubt there is more than theory behind it. Not saying estimates are not important but beeing able to draw much conclusions from a few sprints did never really give a good idea of what is infront of us. It is equally good to just talk to a senior engineer and get a rough idea how many stories a team can complete…

2 Likes
17
  1. Focus on priority, not release date
  2. Don’t suggest a release date until you’ve gotten a technical opinion
  3. When you communicate release date, use the word ‘targeting’
  4. Never give a specific date, always say ‘we’re targeting this sprint/this quarter/this year’ - every feature falls into the bucket of current sprint, current quarter, current year, or later
  5. After you’ve story pointed the work, let the stakeholders make decisions around priority. Tell them, this team completes 40 story points each sprint. We have 120 points of work - what should we work on now? Make them decide.
1 Like
18

By quitting as they don’t want to understand product and that a roadmap is not a Gantt chart.