Protecting Makers’ Time

9 min readJun 13, 2020

As Product Managers we don’t really build things, but rather facilitate and empower other teams (engineering and design) to do so. I’ve described, through analogies, some of the roles that we play for our teams.

Our role is complex and can encompass a variety of jobs and task. From understanding users’ problems, gathering requirements and competitive analysis, to defining business models, growth and monetization strategies and, sometimes, we bring the donuts, just to name a few.

But all the strategic and tactical work that we do, would be for naught if it wasn’t for the group of talented engineers and designers that, like in my analogy of PMs as architects, work with brick and mortar hand-in-hand to build the products that we can only visualize in our heads and describe through our product documentation.

So, one critical role that we need to play, in order to increase the chances of success, is that of protecting our makers’ time.

Here are some strategies to help you manage and triage the never ending onslaught of requests that, if left unattended, would break havoc on your makers’ abilities to focus and get the work done:

Say No… a lot:

If you want to be an impactful Product Manager you just need to come to terms with this. This is definitely the not-so-sexy part of our jobs, but it’s a crucial skill to have never the less.

I know that we all go into product management because we like to build things and get things done, but the reality is that you are always operating under resources and time constrains, and saying YES to every request that comes across your bow is a sure way to sink the ship.

Steve Jobs described the level of focus required to achieve important outcomes when he said…

Remember that one of the key objectives of our role is to solve key problems and to deliver valuable outcomes to our users and the business, and as Patrick Lencioni said: “If everything is important, then nothing is.”

The only way to get to the few and key YESES that will make you, your product and your organization successful is by learning, and being comfortable, to say NO to the thousand things that you “could” be doing but that wouldn’t deliver any value or the desired outcomes.

Building products requires that we can move between the macro and the micro views and be able to focus on details. And when it comes to building truly successful products then all details matter… it’s just that some details matter more than others. And to be a strong Product Manager you must learn how to tell them apart (see urgent vs important section below)

No one wants to have to say or heard the word NO, but this is a much needed reality of our chosen profession. The trick is to learn how to say No without making the person initiating the request feel like their needs don’t matter or damaging the relationship. If you are looking for some inspiration on how to handle these situations, you can start here.

Clean the backlog of dead tickets:

Whether you go Marie Kondo on your backlog or choose other methods for tidying up the house, a clean and well groomed backlog is essential to help you maintain product focus and clear priorities.

Some strategies that I’ve used in the past include:

An icebox project where to store low/deferred tickets or, may be, where to keep all your tickets while your active backlog contains tickets for the next 3–6 months of your product roadmap
Purge out tickets that haven’t been updated in N+ months (if a low priority ticket hasn’t been touched in 12 months, do you really need it still hanging around and clogging your tidy backlog? If you delete it and at sometime in the future it does become a bigger issue/priority someone will create a new ticket for it)
Have a well structured template for how tickets should be written (they should contain enough and clear information and details for an engineer/designer to be able to understand the request and formulate a good idea of the work — constrains, dependencies, timelines — required). While anyone in the organization should feel free, and welcome, to contribute ideas on how to improve the product (bugs, features or enhancements), at the same time it shouldn’t be too easy where anyone can write a line or two through stream of consciousness and without taking the proper time to provide enough information to make the request’s value clear and actionable. Having requirements and guidelines that must be met when writing new tickets helps filter out the “I just thought of it” from the “here’s a new feature, WHY we need to build it and WHAT value it will deliver.” Any ticket that doesn’t pass muster gets automatically rejected.

The goal is to have quality tickets… not necessarily quantity.

Detailed Product Requirement Documents (PRDs):

Whichever product/software development methodology you follow, one thing is a constant: the need for clear, detailed and well written requirements.

This doesn’t mean that requirements have to be long and/or complex. Just that they need to address and provide as much information and details as needed by the teams in charge of their implementation (i.e.: engineering and design).

Do you need to specify the security password policies? How about defining the MAX length for an input string? How should form validation and errors be handles? There’s no easier way to learn how to write requirements than by having an open conversation with these two teams and letting them help define the level of granularity desired.

Remember an important rule of good communication: it doesn’t matter how well you understand a concept and how well you think you are communicating it if your audience can understand you.

Clear Desired Outcomes:

Lewis Carroll said it best…

If you don’t know where you are going, any road will get you there.

I’ve been in the technology/software world long enough to know that our best laid out plans and strategies don’t survive the product development process intact. We pivot and adjust as we discover new data points and increase our learnings. But it’s important that we spend some time and effort, early on, forming and defining a clear vision for the outcome that we are after.

Adjustments are, in my experience, unavoidable (especially if you are taking some large, although calculated risks) and, many times, necessary. But what we want to try to avoid are large side-to-side swings (i.e.: throwing spaghetti at the wall hoping that something sticks). Starting with a clearly defined outcome helps provide the North star that should guide all your decisions and course corrections.

Remember Eric Ries definition of a pivot…

“A pivot is making a change in strategy, without a change in vision.”

Separate the urgent from the important:

I’ve always loved this quote attributed to Dwight D. Eisenhower:

“I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent.”

If you can understand and recognize the incredible wisdom in these few words, then you will understand why Peter Drucker hit the proverbial nail in the head when he said:

“There is nothing so useless as doing efficiently that which should not be done at all”

Which brings us to Jeff Bezos strategy for making decisions:

Two type of decisions: One-way and Two-way

No matter what company you work for, you’ll always run into time limits and resources constrains. In my experience, the amount of work to be done and prioritized grows exponentially to the resources and time available.

As such being able to separate the urgent (two-way doors - about 80% of the decisions) from the important (one-way doors - about 20% of the decisions) is a crucial skill for any Product Manager to have. Unfortunately, this soft skill can only be gained from time in the trenches and making few mistakes that will provide you with a few good learning lessons (hopefully those learning lessons fall under the two-way door category).

Bring the donuts!!!

Makers’ time requires long and uninterrupted periods of time and concentration. Like all good athletes, our engineers and designers need to be able to get in the zone and remain there. Any interruption, however minor it may appear, can cause a loss of concentration. Studies have demonstrated that after such an interruption, it can take up to 25 minutes for a person to get back in the zone and to their previous productive levels. So anything and everything that you can do to help avoid unnecessary interruptions will be very much appreciated by your makers teams.

Having cut my teeth as a Product Manager working for small startups provided me with plenty of opportunities to find small and big ways in which to allow my makers teams to remain in the zone: from attending stakeholder meeting on their behalf and then providing them with a summary of what was discussed, decided and action items, to running errands (dry cleaning, get gas in their cars, go to BestBuy to buy them a pair of headphones and more) on their behalf to ordering dinner (and a few drinks to go along) during long coding nights before a deadline and in the mornings getting coffee and bringing in donuts!

Rules of Engagement (ROEs) for Makers:

Responsibility and accountability are very important to me. I do my best to hold myself accountable and expect the same from others.

So when I engage in planning with my engineering and design teams I give them a few basic rules that they can use to manage any “requests” that may come their way during a development/sprint phase (i.e.: makers’ time). They are welcome to use them, or not, and they can apply them to anyone in the organization, stakeholder or not, including me and all my fellow Product Managers. When a “just one more ask” comes their way, they can:

Before a new development/sprint cycle starts:

Redirect the request to a Product Manager: “Did you talk/ask my Product Manager?” Or the more direct one: “Talk to my PM first” — NOTE: this is NOT to be construed as PMs being a bottleneck or wall between the rest of the organization and the engineering and design teams. Everyone in the organization should feel free to talk to Engineering and Design and vice versa, but other teams should be mindful and aware of how their ask may impact these teams maker’s time
Empower engineers and designers to reject tickets (or whatever artifact you use for communicating the individual pieces of requirements/work to be done) if they don’t contain enough and clear information on what needs to be done

During a new development/sprint cycle:

So your maker teams have agreed to some deliverables and have put their heads down, got in the zone and started work. At some point during the development cycle you, or someone else in the organization, comes across a truly (you’ve done proper analysis, dotted the i’s and crossed the t’s) important and urgent requirement (yes I know… very rare) that needs immediate attention, what do you do? The best strategy, especially if you are following some sort of Agile methodology is to present the request (the WHAT and the WHY) to the team and provide them with the following options:

Say YES to the new work request while still remaining committed to completing what’s currently on the schedule/sprint
Say YES to the new work request but ask that something that the team has committed to in the current schedule/sprint is removed
Say NO (obviously it’s a good idea for them to have a good and valid reason why they are declining on taking on the new work) and reconvene, after the development cycle is completed, to re-evaluate the importance and urgency of the ask.

When presenting these options to the maker teams, you need to make it absolutely clear that it’s THEIR choice which option they exercise. If they pick #1 or #2, they should be held accountable for the outcome; while at the same time you need to respect their decision if they go with #3 and assure that there are no consequences to the teams.