Your PM Process is what? (not Engg process)

Ujjwal Trivedi
7 min readAug 23, 2020

Simon Sinek says we should “Start with a Why”. So let me start this essay as well by answering why should we even have one on this topic. Because product managers are struggling, globally. The expectations from the PM are almost superhuman, and there is most likely no standard path, situation, or training given to PMs that sets them up for success.

You’d see that while they’d talk about lean and design thinking etc. they mostly DON’T end up using any of those. Why?

Most organizations want to come out of the rut of feature factories, but they don’t, they can’t. PM Resumes are full of what they built, not how they made an impact.

Product knowledge is either in the test cases or in the head of people who originally worked on them. They live with poor documentation, they can’t find enough time for fixing it.

They want their PMs to be more empathetic, more user-centric, prioritize better, manage stakeholders and deliver faster.

Where is the process to deliver on all these expectations?

I have seen many orgs end up making huge Product Management teams and lean heavily on Engineering processes but not enough PM process to ensure their PMs are doing well. While everyone is focused on productivity and quality of Engineering, but the processes for quality PMing is negligible or non-existent.

Here is why a PM-Process is extremely critical:

  • We’re always Firefighting: PMs lose focus on business objectives and find it difficult to prioritize correctly — leads to more firefighting, “busy” work, burnout. This also leads to building things no one really wants — or more surprisingly features that they say they want but still don’t adopt. You can’t really be creative when your ass is on fire.
  • Loss of Engg Effort and Productivity: PMs keep hopping from building one feature to another instead of achieving the outcome — this leads to customer frustration, loss of engineering bandwidth, worst of all loss of motivation. UX Coach Jared Spool has some amazing insights on the cost of frustration.
  • Complex product: PMs work on islands, they focus on their specific areas/modules/features instead of the user’s whole experience. That makes them look for unstable hacks, workarounds, or complicated features that end up creating a complex, less maintainable product and a never-ending Tech Backlog.
What’s your PM Process?

How did we end up here?

If one or more problems look relevant to you, do spare a thought on how did that even happen. I’d ask another why. Why is this happening?

  • No set process for PMs —you are mostly making ends meet, building one feature, and hopping on to the next feature
  • No templates for requirement gathering, design, documentation (PRD/Jira ticket), release notes or user manuals, or if there were templates in the beginning — no one knows now.
  • No quality check on PMing — no formal channel to gather PM’s efficacy. Tracking it back from Product failure is too little, too late.
  • Frequent change of direction — while sometimes this is circumstantial, short-term planning and sticking to the plan is critical for efficiency, keeping up motivation, and avoiding burn. It could be you doing it or HiPPO.
#burn

So, what do we do?

So here are the 2 steps that will, over a period of time, help you get rid of all these problems.

  1. Articulate your PM Values and Principles
  2. Create and Follow a PM Process(s)

PM Values and Principles

This HBR Survey suggests that more than 80% of the companies that say they follow Agile, don’t truly follow agile processes. Oops.

The Agile Manifesto — it is an amazing set of guidelines for building your own process. It is drawn from some core values and then some guiding principles that help us enforce those values. While the Agile Manifesto is extremely effective, those who try to stringently follow scrum, or XP, or other set processes based on the Agile manifesto, have burnt their fingers.

Processes are D-I-Y. Copying processes are the root cause of all disappointment. How do you decide what process to build? TBH any process, in most cases, needs to be very contextual and temporary. Processes will change based on your maturity and need. However, most good processes are based on certain principles or values that would most likely remain unchanged for a very long time.

Here are some product management values for starters:

Empathy: Being Empathetic creates trust and helps the PM lead without authority. Also, helps PMs build the right thing, reduce ambiguity, avoid tussles, boost morale. It also involves creating readable documents, responding quickly to emails, and creating delightful user experiences.

Curious: Being curious is a precursor to being innovative. Probe the customer, probe the stakeholder, probe the market, probe the existing data. Is there a better way to design it, do it, market it, sell it?

High-Agency: High Agency person looks to bend reality to their will(Copied from this awesome twitter thread). They either find a way or make a way for themselves. If you are high-agency, you Get things done.

ROI Focused: As discussed earlier that we should start with a Why. Focus on how much value the user or organization will be getting because of this product/ feature/ change/ tweak leads to faster/better decision making. Ask: Is it worth the effort that we are going to put in?

Clarity: The world is messy and getting messier. It’s important to constantly reduce entropy by creating reasonable plans and sticking to them. Document unambiguously, use simple and clear language with visuals, go the extra mile in teaching all stakeholders the value, and working of what’s been built.

PM Principles

The guiding principles are derived from the values, that help us with two distinct things

  1. Put values into practice
  2. The principles help us create and improve different PM processes so that we can solve the problems identified at the beginning of this essay

Here we go the 8-Fold Path:

  1. KYC (Know your customer): Distance relationships don’t work. The longer we stay away from clients the higher the chance of us losing control over priorities. Dedicate time periodically to talk to a client/potential client — internal or external. Additionally, attend a sales call or a client demo. In some projects you’d easily get a chance, in others, you will have to make efforts to talk to your clients. It’s not a one-time thing, it’s a continuous activity. #empathy
  2. Think Problems, not solutions: The magic is in defining problems such that finding the solution is reduced to a logical/mathematical problem. #roi-focus
  3. Show, Not Tell: Be as visual as it gets. Add screenshots where you can, A high fidelity wireframe is better than a hand-drawn one is better than nothing. Write copy, not lorem ipsum, the copy is design. Don’t limit yourself to telling stories when you can show them. #empathy #clarity
  4. Own the Emotion: A product is not just getting the correct feature/ functionality — it’s getting the correct emotion. Measure emotion, not just numbers. Emotion comes from the overall experience — that includes the full suite of features, products that the client uses. Keep an eye on the complete experience not just your specific feature/product. #empathy #high-agency
  5. KYP (Know your product): Eat your own dog food. Invent ways by which you, your team, or some internal team is able to use the feature and give brutally honest feedback. If you can’t use it no one will. #empathy
  6. Think Outcomes, not Output: Read the following like a pledge — “We are here to manage products not produce features in a feature factory. Building the feature is just a 20% job done. We think why we are creating it, we write down the impact, we measure the impact of that effort over a period of time. If they aren’t using it, our effort is wasted.” Repeat: We measure emotion, not just numbers. #roi-focus
  7. Ask: Ask what’s new (and what’s stale). Prod the clients, the stakeholders, the engineers, the data. Question the current state, and ask if there is a better way. #curious
  8. Write it down: Life is short, and memory is fleeting. Write down your thoughts, specs, sprint themes, roadmaps, plans, and the reasons for making those decisions or making that plan. Document key decisions and thoughts in a shareable artifact and share it with all stakeholders. #clarity #high-agency

Product Management Processes

Success is a process. This 8-fold path can help you build PM processes based on your context, maturity, burning need.

Processes will be contextual, temporary and you should evolve them with your team, not in your cabin.

I am not describing the processes I’ve built, because they are contextual and suited very specifically to the orgs I’ve worked with. However, if you absorb and articulate your PM Values and Principles they’d surely guide you to create the right processes.

For example,

  • the Think Problem, not solution principle can lead you to create a documentation template or a checklist(better) where all your docs start with problem analysis first. Additionally, you may need a temporary process to foster this documentation discipline among all team members.
  • Own the emotion may suggest a need for regular communication and coordination among different product peers/teams. A Bi-weekly demo/standup?
  • KYC/KYP can suggest adding a step in your regular documentation/release process. If it ain’t dogfooded it ain’t released!

So, this is how I’ve helped some organizations create their PM processes so that they are able to realize their product goals.

If you have any issue in creating your Values/ Principles/ Processes I can help. When you focus on the PM’s problem you are trying to solve, articulate your PM Values and Principles — the process part will be easy.

Those who don’t clap for a good prose, they die of starvation. — Abraham Lincoln(said in my ears)

--

--

Ujjwal Trivedi

Products guy | Sr. Director Products@ MoveInSync | Ex-Artoo Fintech | Ex-CouponDunia | Economics | Cognitive Sciences | Poetry | Volunteer/Director @ Headstart.