Stop firefighting PMs: Cheers to Processes!

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. I have seen many orgs end up making huge PM teams and lean heavily on Engineering processes but not enough PM process to ensure 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.

What’s your PM Process (not development process)?

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.

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 did this happen:

• 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 or HiPPO.

#burn

So, what do we do?

So here are some solutions that will, over a period of time, help us get rid of all these problems.

1. Articulating your PM Values and Principles
2. Creating/Following PM Processes

PM Values and Principles

PM Processes will change based on your maturity and need, but your PM values and principles 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. 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. #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 our 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: If you aren’t measuring, you are not improving. Ask about business goals for every decision, call out when the goals are unclear. Building the feature is just a 20% job done. 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, 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

PM 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. And 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.

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.

Thoughts? Questions?

--

Originally appeared on medium