Published on | Prototyping: From UX to Front End — Medium Andy Ayim Unsplash

In my last post I laid out 3 issues with Enterprise companies that cause them to fail to innovate due to the way they set up and run product. You can read my last post here. Product Management has risen in popularity this decade, however it is one of the most broadly defined roles in tech. Some companies have Product Managers (PMs) in the same organisation as Marketing, others alongside Project Managers. Most PMs would ideally report into a CPO (Chief Product Officer), however most report into a CTO (Chief Technology Officer). Some organisations mistake a Product Owner for a Product Manager when they are not one in the same. Most PMs face the challenge of taking the business on a journey at Enterprise scale and usually spot a number of red flags along the journey.

<a href="https://medium.com/media/f90687f27bae9909a0bdf42fffe77328/href">https://medium.com/media/f90687f27bae9909a0bdf42fffe77328/href</a>

One of the most important red flags to address is that Products are being run like Projects with ‘Agile Roadmaps’ really referring to ‘Waterfall Project Management Gantt charts.’ The question becomes:

How can you wean management off Roadmaps?

1. Establish Accountability & Ownership

Many PMs have been in the difficult position whereby senior executives share ideas and solutions they want you to build. Often the thing that is overlooked is that not all good ideas come from executives. The first step a PM should take in this tricky situation is to slightly adjust your roadmaps to hold business owners accountable.

Take this scenario below with the Chief Commercial Officer, Rick and the PM, Akua.

Rick: “Akua, do you think we could build Chatbots in the next 6 weeks?”

Akua: “Why Chatbots?”

Rick: “Because we could use Chatbots to acquire more Business customers”

Akua: “Ok, so the goal here is that you want to acquire more Business customers?”

Rick: “Yes, it costs us nearly $400 to acquire a new Business customer and we have missed our target of 12 new customers for the last 3 months”

Akua: “So the problem you would like to solve is…..how can we acquire <12 Business customers a month for less than $400 each”

What our PM Akua did above was extract an Objective and Key Result from her senior executive by being curious and asking the right questions. This ability to ask why and get to the route cause of a problem is a key trait of a strong PM.

In the case above Akua could try out Chatbots and hold Rick accountable for the results which would likely be poor as he went straight to a solution rather than provide a problem for Akua to validate through Product Discovery. The above could still be laid out in a feature-led roadmap, however the poor results builds a PMs case for change.

2. Product Discovery

Discovery vs Delivery

By no means is this a blame game or an opportunity to say “I told you so,” but rather an platform to provide an evidence-based case for change. For example, if Akua agreed with Rick that a measurement for success (key results) was “acquire 12 new customers a month” yet only 2 customers were acquired a month, then Akua can show that despite delivering on Rick’s request, the results were sub-optimal.

Once exec’s experience this even 2 or 3 times, they lose patience, struggle to understand why their ideas keep failing and become eager to try anything to achieve results as their competition gain market share.

This is the PMs opportunity to introduce Product Discovery. The goal of discovery is to learn FAST, instead of learning after shipping our product that nobody wants it. We want to learn as quickly as possible if what we think we should build is the right thing to build. This is where PMs work closely with UX and Engineering to develop prototypes and carry out customer testing to address the 4 following risks.

VALUE RISK: Will users want to use or transact with my product?
USABILITY RISK: Will users know how to use my product i.e. without an explainer video?
FEASIBILITY RISK: Can we technically build this i.e. given our tech stack?
BUSINESS VIABILITY RISK: Is this product viable from a Business perspective i.e. Can we do this from a regulatory perspective?

Product Discovery will lead to ~70% of ideas getting killed or iterated upon and changed. However ideas can progress with confidence into Product Delivery whereby Engineers can build things that have been validated.

This article has shared how PMs in Enterprise scale companies can begin to wean off management from Waterfall-style roadmaps. In my next article I will share the alternative way to manage products in the absence of roadmaps. Sign up to my newsletter below to stay posted!

Credits: Marty Cagan from the Silicon Valley Product Group, he taught about this in practice!

Learned something? Click and hold the 👏 to say “thanks!” and help others find this article.

<a href="https://medium.com/media/6a088c9218e1ba9ed2e1962ac96450ec/href">https://medium.com/media/6a088c9218e1ba9ed2e1962ac96450ec/href</a>

An alternative way to run Product Teams (part 1) was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

An alternative way to run Product Teams (part 1)

Cool stuff, every week

More Articles