Dealing with Top-Down Projects

 Q: My manager keeps instructing me to build certain features that were decided on by management without my input. I’m not happy not to be consulted, and I disagree with many of these ideas, but my manager always presents them as  a “must” and is not willing to challenge the decisions. What can I do? 

I feel your pain — I found myself in that same uncomfortable position more than once during my time as a product manager. Many product people I speak with face that same challenge.  

Here are common options which you probably already know:

• Disagree-and-commit — sometimes that’s the right thing to do, especially when this product change is part of a much larger initiative, or when you’re still junior or new to the team. However, constantly asking people to commit to top-down decisions isn’t a good way to lead. Your opinions should matter, and you should have some control over your area of responsibility. 
• Seemingly agree, but drag your feet hoping the project will go away — may work sometimes, but is quite dishonest and soul-crushing. From experience, this is not the way to go.
• Talk with your manager — If this is a repeat phenomena, it’s a good idea to have a one-on-one with your manager. Give a few examples and explain in a respectful and non-accusative way why receiving these directives is a problem for you, and how it makes you feel (make it about you, not them). In my experience these discussions always lead to some improvements: the manager will try to involve you more, and you’ll understand their perspective and motivations better. Still, your manager may not know what’s the alternative, and many things are outside their control. 

There’s another option — hardest, but potentially most rewarding — create the change you want to see. 

I’ll explain what this means below using the four layers of the  GIST framework: Goals, Ideas, Steps, Tasks.

Find the True Goal

When your manager is asking you to build feature X, they’re in fact giving you an output goal. 

Your first mission is to: a) discover the real outcome your manager is after, and b) make the goal about that outcome 

Let’s say your manager says something like “We should redesign the payment flow to be more like Stripe’s”. 

Asking “Why?” may come across as argumentative. Instead qualify, with a statement like “Understood. There are multiple differences, though, so just so we focus on the right things…”, then you can ask question like: 

• “What specifically do we see Stripe doing better?” 
• “What caused this idea to come about?”
• “What should change in the metrics if we’re successful?”

If you dig enough, you may find the backstory. The executive team may have concluded that payment completion rates are too low (that’s legitimate — management teams should discuss such matters), someone argued that the design of the payment flow is the problem, someone else pointed at Stripe (a market leader) as a positive example, consensus emerged, and your manager ended up with an action item to redesign the payment flow to be like Stripe’s. 

(Obviously not all management decisions are this simplistic. Some managers agonize long and hard over which product ideas are best. Sadly without real evidence, and without involving the people doing the work, the quality of these decisions isn’t necessarily any better.)   

Now you can create an outcome goal:

This is not a perfect OKR — it has only one key result, and the objective still mentions Stripe. But it’s  good enough as a start. You’re not trying to remove the redesign-like-Stripe idea off the table yet, just to agree on what success really means (if you’re new to OKRs – here’s a short guide). 

Most managers will accept this goal, but some will ask to add  “Launch new payment redesign similar to Stripe’s” as a key result. You can explain that launches make for bad KRs — many managers know this already — but if your manager insists, add this KR, and dispute it later with data.   

---

Join thousands of of product people who receive my newsletter to get articles like this (plus eBooks, templates and other resources) in your inbox. 

---

Identify Other Ideas 

“One of the things that really hurt Apple was that, after I left, John Scully [Apple’s CEO] got a very serious disease […] It’s the disease of thinking that a really great idea is 90% of the work and that if you just tell all these other people ‘here’s this great idea’ then of course they can go off and make it happen.”  — Steve Jobs / The Lost Interview

Jobs is talking about the classic-management worldview where it’s managers’ job to come up with the right ideas and employees’ job to execute on them. This may have been true in the early parts of the 20th century, but today we have a different world view:

• For any given goal there can be more than one possible idea.
• Most ideas will not create a meaningful difference, though (some will have negative results). 
• To find the ideas that truly work we must quickly and cheaply assess and test multiple ideas and invest only in those that show supporting evidence (product discovery).
• Management teams don’t have the time, tools, skills, and subject-matter expertise to evaluate, and test ideas and to analyze evidence. That’s the job of product teams. By having product teams do this work (transparently and objectively, and with feedback from managers) we’re not disempowering managers, we’re making them far more effective leaders. 

So your next step is to surface other product ideas that your managers may have missed and to show how they compare. To do this you’ll likely have to conduct some (ideally quick) research. For example:  

• Analyze payment flow data to see what’s causing abandonment or failure
• Run  a usability test with 12 participants who are given the task of completing a purchase using your current flow and Stripe’s.
• Ask your UX designer to  compare the differences between your flow and a few other leading examples, including Strip

Next you can share your findings with your team and discuss ideas. You want to come up with a list of 5-8 ideas for improving payment completion rate. Involving the team early gets everyone engaged and motivated, and greatly helps in finding better ideas. There’s another, somewhat political, benefit — companies typically want to keep engineers happy and will look more favorably at ideas that the team supports (PMs’ feelings are far less of a concern). I recommend collecting your ideas in a mini idea bank and analyzing them using ICE (Impact, Confidence, and Ease).

---

We learn in-depth how to implement evidence-based product discovery in my Lean Product Management courses. Secure your ticket for the next public workshop or contact me to organize an in-house workshop for your team. Learn more at itamargiladcom/workshops.

---

Share The Ideas and Adjust the Goal

Now is the time to go back to your manager and share your research findings and your mini-idea bank.  You’re now in a better position to offer a better goal:

• Objective: Improve payment completion rates 
  • KR: Grow transaction completion rate  from 34% to 42%
  • KR: Reduce transaction timeout failure rates from 12% to 3%

The response of your manager may vary:

• Some managers will be furious at you for “wasting time and resources ” (actually for disobeying commands). They will direct you to immediately build the Stripe feature. If this is the case, my best advice to you is to polish your resume and to start interviewing for a role at other companies or in other parts of the company.  Life is too short. 
• A more likely reaction will be mixed — the manager will like the initiative, and will acknowledge that you may have found better ideas. At the same time they’ll be worried about lost time and effort and will wish you progress on building something as soon as possible. 
• In the best case the manager will be very pleased. You’ve demonstrated you can work towards a business goal in a lean/agile way — something many product companies now desire. The manager may present your OKR and idea bank to the executive team and as an example of a job well done (side-benefit: you made your manager look good). Important discussions about goals, ideas, and confidence levels, may follow. Other teams may be asked to follow your example. This can be the start of an important change.

Keep Building-Measuring-And-Learning

Even in the two “happy scenarios” above you may be asked to just pick the top idea, build, and launch it. It’s hard to let go of output optimization. It’s possible that in the first cycle that’s what you’ll have to do. Still you have achieved a lot by changing the goal and picking an idea that (on paper) makes more sense. 

But, if you’re given the latitude, you should keep validating your ideas in build-measure-learn loops (called Steps in GIST terminology). You can run A/B experiments, conduct fake door-tests or use other quick validation techniques (here’s full list of ways to  test product ideas), 

It’s important to demonstrate that the scores keep changing with new learnings and what looks like a strong idea one day, may turn out to be weak after a test or experiment. Importantly, with each test you’re also developing the idea and moving it closer to completion. Eventually you should end up with one or more ideas that are strong enough to build in full (delivery), and those will likely be already half-built.  

Your team may not be used to combining building with learning. They may push you to define backlogs and user stories for things that should be fully launched. Try using the GIST board and the techniques described in this article to work better. Again, this may be too much change for a first cycle, so you may defer changing the way the team works (the Tasks layer of GIST) till the next cycle. 

Celebrate Success and  Share the Learnings

Hopefully soon enough you’ll start seeing positive results — improving payment completion rates.  This is no small feat — many companies struggle to move any of their metrics.  Consider holding a retrospective to discuss what worked well and what needs improvement, and then share the learning broadly inside the company. At best this will become a case study to learn from and to replicate, catalyzing a change towards true lean/agile product development. 

Start the Revolution

Your goal is not to prove your managers wrong, or to claim your rightful ownership of the product. This would be the wrong mindset. The goal is to explore a new way of working that is better for the business and the customers, and more empowering for both managers and team members. 

I can tell you many management teams want to switch to a more lean/agile/user-centric mode of work, but they just can’t imagine these apply to their company. By providing a positive example (which may not be perfect), you’re making the change clearer and more tangible. Everyone can see that switching to evidence-based product development isn’t science fiction. You will not be able to transform your company single-handedly, but you can sow the seeds of change and get other people to believe and to contribute, which ultimately can bring about the change you hope to see. 

Cover photo: Jeff Sullivan on Flickr (CC BY-ND 2.0)