PRODUCT VS PROCESS

Is your product development process creating more problems than it’s solving?

I’ve been in all types of startups from where there’s no product development process at all, to a startup that established a programming military machine as their go-to product process, and a startup where I implemented a product development process myself.

Something interesting is that each startup, each team, and each product is a new world, and even though each of them operates differently, there’s always something that joins them: The Process. Because even if you have no established process, at the end it’s ad hoc process or an on-demand one.

Building a product is a cross-functional endeavour, as PMs we must deal with everything and everyone, we are the ajonjolí de todos los moles.

The Product’s outcome is on the product manager, in other words, the product manager is ultimately responsible for the success or failure of a product, and I say no one and everyone, because, we PMs don’t have any authority over any of the people involved in the collective effort.

So we are no one’s boss, but at the end, if the product fails, it’s our responsibility; sounds like a Catch 22 to me. That’s why the Product Manager should always have a card up their sleeve: Process.

Process, in my point of view should be established into three areas:

1. Communication;
2. Autonomy; and
3. Execution.

Let me explain with an example; many startups and product teams have adopted Objective and Key Results (“OKRs”): please read my article about OKRs if you don’t know what they are, and also so you can establish better NYE resolutions.

OKRs, are a great example of a process that establishes Communication, Autonomy, and Execution.

Let’s say a company’s main Goal aka Objective is to increase brand awareness, that would require a couple of key results; maybe improving the landing page, adding a product tour, increasing the signup funnel by xyz%, and so on.

What’s interesting about this example, is that you are i) communicating at the company or team level the main objective; but you leave ii) autonomy to the team of how to solve this, and how such iii) execution will be measured.

So any process, should follow such schema, unless you are reading this in Fort Bragg and you want to apply it with your squad, be my guest but demanding is not the same as communicating.

So moving back to Product Development Process, how do we establish certainty, replace chaos with order, in a such a fast changing world? Maybe a process that solved yesterday’s problems could block a team from developing tomorrow’s solutions.

To answer that, let’s begin with my dad used to tell me:

“Maybe you have no idea what do you want to do, but hell you know what you really don’t”

And damn he is right, we will focus another post on the how to establish a process, but let’s first check, what your process should not do to your team:

No No No Process Warnings

1. It takes twice the planning & execution of the process, than the actual execution of the Product.

Sometimes it’s easy to underestimate the time and cost of executing a process with the product & Dev team. If the managers are asking for 1 Pagers, Pagers, user flows, low-frames, high-frames, wireframes, Mocks, PRD (product requirement doc), Postmortems, Sprint Planning, Mid-Sprint Review, costing, burndown charts post this and that. You could get lost more on the planning and reviewing than actually executing the product.

2. The cost Opportunity between process and customer validation

All product managers have the same 24 hours, and it’s up to the best PM’s using their time talking to the customer rather than going through a bureaucratic development process.

Product is King, but the User is the King of kings, and if the product development process is not centered towards her you are just wasting your team’s time.

3. Making a process non-iterative one

The life-cycle of the Product is dependent on its iterations, new incoming variables, and in & out factors, and that’s how the Product process should be.

We must always allow the process to murmurate in a constant flow🚀

(this was a gif, but Linkedin is not a gif lover)

This appeared first on Medium. If you enjoyed this post, please hit the “recommend” ❤ button below.