Process – PM'ing

The PM-o-Matic

At my first software industry job (Cataphora, an enterprise search and NLP startup), the CEO, Elizabeth Charnock, ran an in-house leadership training program, which was mostly just her sharing her thoughts on leadership. One of her main messages was that management was about being willing to make decisions, even though you’re probably wrong. You should try to make an informed, fair, optimal decision, but you very rarely have that privilege. Most people’s decisions are not optimal most of the time, and you should get used to, rather than fear, being wrong. The worst thing you can do in the face of incomplete information was abdicate making a decision. Being afraid of being wrong, and making the implicit or null choice was far more fatal. Her key to getting comfortable as a manager was to get comfortable making decisions even in the face of uncertainty and disagreement.

Fast forward a few years, and I was a first time product manager, in a mid-size mobile startup, where there were no other product managers or pre-existing patterns to follow. People from different functions would come ask me classic product questions, “can this product do this thing we thought of?”, “I need to tell a client this feature will be ready in a month, will it be?”,”whats the status of this bug thats annoying me?”, “can I cut this use case out, it will save days of development”… and so on… and on.

I tried to document and delegate, but when cornered, to answer questions and make decisions the best I could: informed and goal-focused. But I also remembered that leadership training. It was important to me to never abdicate a choice brought to me. Not to always have the answer, but to always be the decider or the delegator. But I also heard, and found to be true, that this was a mentally exhausting way to live. After a month or two my engagement with these small day-to-day decisions began to flag. I also read, around this time, that there is a limited amount of cognitive effort available in a given day, and decision making burns a lot of it. Some execs handle this by wearing identical clothes every day, sticking to strict life patterns, and otherwise trying to minimize the unimportant decisions they make. I decided that my way to handle this would be to take a piece of cardboard about the size of a piece of copy paper, and use a marker to write YES on one side, and NO on the other. Then, when someone came to me with a question, or decision point that I thought was basically a toss up, or where I needed to preserve my mental space and energy, I would flip the PM-o-Matic in the air, like a giant coin, and that would be my answer. Really.

I’m not sure how often it served as just the starting point to a conversation or negotiation, and how often its decisions actually stood, but I do know I felt like I was leading, but that some of the mental burden was off. Oddly, most people didn’t mind, its ridiculousness became a way to diffuse sometimes tense discussions, and mostly they were just happy to have a clear answer.

Two years after I left, I got a text from a former co-worker. It was a picture of the PM-o-matic. She had saved it after I left, and was now leaving too. She said she always appreciated my use of it to resolve questions quickly and with a sense of humor. I don’t use the PM-o-Matic anymore, and it’s certainly not something that would pass muster in a sophisticated product organization. But I’d still recommend it over making no decision.

Essential Cycle Meetings

Although the frequency, length and details may vary, there are some regular gatherings which I think are fundamental to building and maintaining “flow” in a high functioning software team. Here is my list of essential cycle meetings:

Grooming – Triage new tasks from your inbox (your task inbox, I mean). Assign all tasks a priority, and sort into backlog or active development flow. If there are no inbound tasks, review backlogs in priority order, closing or refining tasks only. Grooming can be a PM solo activity, a team leads activity, or open to the full team. Generally, it’s a waste of most people’s time, though. But for PMs and team flow, it is vital.
Planning – I prefer to do this weekly, but bi-weekly can work. This is the core team meeting. You can use it to review planned work, or work in progress. This is also the forum for longer presentations and proposals, and to have medium scale planning discussions. Always track action items and decisions, or have someone who does.
Stand-ups or Syncs – Short meetings to discuss the state of work and identify any blockers to progress. Lots of people like the “yesterday, today, blockers” standup format, where each team member gives a very brief overview of their work yesterday, today and brings up anything blocking their progress on current or upcoming tasks. Slightly longer sync meetings can also be useful. In that format the focus is often on the board and the progress of priority tasks, and burn-down, rather than team member status. This is particularly useful if deadlines are looming or as complex products, features or releases are in the “coming together” phase.
Retros – Facilitated discussions of the good, the bad and the ugly. If your group or organization doesn’t have people who can act as facilitators (scrum masters, project managers, etc), be sure to use a standard format, to avoid the temptation to monopolize the conversation, or play the process “by ear”, and thus bias it. The most important meeting if you want to improve the team, yourself or your product.
Walk-throughs – Walk throughs are a way for the team to “walk in the shoes of the user” together and collectively identify issues. This is especially good for improving “polish” and usability quality, but isn’t necessary for day-to-day changes. See this essay which gets into detail about this process.
1:1s – have at least 30 minute 1:1 with each team member and key partners or stakeholders every week or two. Always have something prepared to talk about, even if its social, but always defer to the other persons agenda, if they have one. Good meetings to have walking, drinking or eating.

Essential Tools

Software development can be a closed loop. The only tools you need to make software are software. Post-its and white boards are great, but what you really need is good apps. Below I’ll rundown the essential categories of apps and their roles.

Task management – A system where you can track work. You must be able to visualize the work of your team. People need clear task lists and priorities to execute your plans effectively. The most important tool for PMs. PMs who don’t intimately know and have a love/hate relationship with their task management software are PMs who don’t know how to operate a team. Know it, work it, customize it.
Calendars – A shared calendar system is key to almost any business. But for PMs it has special importance. Keep your calendar as public as possible and up to date. Set work hours. Always add agendas or at least comments to any meetings you create. Don’t expect engineers to use their calendars effectively. They often don’t accept or decline meeting requests and may not open their calendars very often. Always follow up in person or email, and be patient, as long as they show up when you need them.
Notes – Most people use cloud note systems, although me and plenty of other people I know use draft emails. It works well, and makes turning notes into/out of emails is easy. But whatever works. PMing is a complex job, you need to take notes, or have people take them for you. Notes and note systems are generally the way that passing thoughts and verbal communication make it into the task management system and thus into reality.
Wireframe or prototype tool – This is probably your UX or visual designers thing, but you should be familiar with this key tool. This is how specs and ideas become interfaces, so it matters.
IDEs – Similar to the above. This isn’t where you live, but its good to be a comfortable visitor. Its also good to know, at a high level, what kind of things their tools make easy or hard. Knowing the pain points in the dev chain is also helpful for understanding team flow.
Terminal – (Or Console or whatever command line interface.) It comes in handy. Its not as hard as you think. It buys you a ton of cred with engineers if you genuinely know your way around a command line, even just a bit.
Collaborative documents – Again, this is a tool any business team needs. But so do you. Don’t work on docs, proposals, specs, and so on alone or on local machine-bound word processors. Open your process up for comments and socializing.
Slideware – Decks are the distilled essence of product management. Persuasion, evidence, argument, narratives, and pretty much the whole job in hypercard form. Unfortunately most people are bad at decks, and give slideware a bad rep. But its worth taking classes or at least watching videos about how to create and especially give compelling presentations. It’s a developable skill and usually the primary high level persuasion tool, so it is worth it.
Chat – I hate IM’ing. But when you work with remote teams or from home, it’s your mouth and ears. Luckily, my distaste for synchronous text conversations is not, it seems, common. So you probably don’t mind, or maybe you even like, instant messaging. But if, like me you’re not a texting natural, you’ll need to learn to embrace it. Some people, often introverts, engineers or ESL speakers, are much more effective communicators over text.

PM’ing in public

I work at a beautifully weird organization. The Wikimedia Foundation is transparent to the outside world in ways most people, even people who know our work (not the projects, but the Foundation) or support it through donations, don’t know.

For a PM, the idea of doing our job in public can be a bit of a challenge. Many PMs operate best in 1:1s and manipulating the flow of information. If things are transparent, not just internally, but, literally, public (as in both free to use/copy and viewable in the internet “commons”), how do you differentiate, prototype or otherwise get the element of surprise, so skillfully deployed by Apple and others? Well, you don’t. You accept that your goal is to be seen and copied, just like our contributors’ photos on Commons, our research, designs and products are to be shared, in the very hope that they will not just be seen and used, but copied and remixed.

But also it means all your tickets, even your teams RETRO NOTES, are there for anyone to see. Dad want to see your teams quarterly update for the executives? Future employer want to see a product proposal you wrote? It’s possible.

At first it weirded me out. I had expected to be reporting regularly to the public (it is a charity, and a place known for advocating transparency on the internet.) I had not expected to have my meeting notes made public by default, or the staff meetings to be streamed live to the world. Now it seems normal. But I had to gain confidence in what I was doing and remember every fucking day that nobody is perfect. My unfinished specs, tasks open and assigned to me way too long, flimsy rationales, sometimes aggressive politicking, they are all there for you to see, but they are not that unique. At least that’s what I tell myself. Plus, what you find is that, like your personality flaws, most people don’t give a shit, or even see the same shortcomings you see in yourself. We’ve had fewer than 50 people ever come comment or get involved with any of the public work my team has produced over 2 years (not counting code contributors). No one has time to read your specs.

And on the other hand, I get to do a job that’s usually among the most “proprietary” in the world, and do it in public. I wish more orgs would let their teams do their process in public. When there is no competitive advantage to secrecy, I think there could be great value to our profession, and the products we create, if more people who make great software could be truly open about their process.

To illustrate the level of transparency I’m talking about, you can see the “dark mode” feature’s development on wiki, Phabricator (our task management system) and public google docs. Not because we set out to do so, but because it is the default. From the planning meeting when the team first prioritized the feature. To the task tree, including the initial design thinking , the interactive prototype, design research presentation, the tech scoping, the implementation and iterations and bugs, the user testing and evaluative research, the QA test plan, the regression testing results, the public mailing list announcement of the beta test, my draft of the App Store text, the release checklist for actually pushing out that version, the clean up tasks in the following bug fix release, a post launch review and analysis I did for my peers, the quarterly report where I took a victory lap for the positive response, and the draft and final the blog post where my team leads wrote about how we approached all this. And that’s not even all the fingerprints of this thing on the public internet. This for a simple (but important) feature. All teams have these kinds of digital artifacts, ours just happen to be public.

If you’re new to product management, curious how it works, or just nosy about Wikipedia and Wikimedia, I recommend checking out some of our easier to digest stuff: our monthly metrics meeting (always streamed live on YouTube), our quarterly meetings, decks and notes, or check out the many links I posted about dark mode. It’s far from a perfect, or exemplary, organization, to be transparent about it. But at least its flaws, like my own as a PM, are all there to be seen, discussed and hopefully improved.

Participatory Product Management

The reasons to make your product management and planning processes more participatory is a subject for another essay. Suffice to say, it’s something I think has powerful payoffs and, for me, is a strong cultural preference. By participatory, I mean involving other people in research, planning and even decision making in a real, genuine way. Anyone can ask for feedback, are you confident that you sold your strategy well internally? Let people vote anonymously, it may surprise you.

I’ve been lucky to work as a cofounder, in small orgs and now in a collaboration focused medium sized org, so I’ve had some practice at it. Here’s some tips for making your product management more broadly participatory.

A Few Ideas

I strongly recommend you adopt a kanban[LINK] or similar queue based work process. Don’t be dogmatic about it, but kanban is based on a pull queue and allows skilled team members to manage their own pace and have a sense of ownership of the tasks they take on. At the same time it allows you to maintain prioritiy and context. I believe scrum systems, in particular any system which requires negotiated sprint commitments is detrimental to the PM’s relationship with the team. It sets you outside the team and is focused on a tension (the scope the product owner wants vs. what the team thinks it can do).
I like to have teams perform a product self-evaluation. We pick a set of aspirations for our product or ourselves, (“sticky”, meaning hitting a certain user retention,”stable” which we’ll define to mean a certain crash rate). Prior to long term planning processes, we anonymously rate the product from 1-10 on these aspirations. This allows everyone to see how their peers feel about what they’re building together. It also can help to focus planning discussions if there is obvious consensus on the areas needing most improvement.
No spectators. All team members should participate in as many process meetings as possible. Design, QA, data analysts, ops, research… anyone who builds, rather than sells, the product should be at stand-ups, planning and retros at minimum. Then, run inclusive meetings. Open up the floor to everyone. Call people out in positive ways, especially if they are marginal (ie. not a lead or core member). Don’t let interrupters and loud mouths dominate. Don’t let men talk over women. Encourage introverts and non-native English speakers to follow up over email or in 1:1s where they might feel more comfortable participating genuinely. It takes work to participate, and it can be a great gauge of engagement and commitment. But in enabling and evaluating participation, be very aware of bias and culture.
In very healthy situations you can actually allow teams to vote on their priorities and it doesn’t turn out horribly for everyone! Here’s how it works: you’ll need a team that has a strategy and is bought into it, has some rough consensus (or a couple is okay), and a reasonable ratio of different functions (ie. this doesn’t work if their are 8 backend engineers, 1 frontend and 1 designer). I have used a weighted voting process to mixed effect, depending on the team, but sometimes resulting in a better plan and very high level of team commitment and deliver.It can be done in person or on a hangout, but in person is more effective at the emotional bonding and buy-in. This is a good activity to do at a retreat or off-site.

I do this after status and strategy presentations and discussions. This puts people in the right frame of mind, and reminds them there are shared goals and constraints they are operating under.
I write up potential epics on large post-its and put them on a wall.
The team write their own proposed epics and post them on the wall. People can ask questions about the scope and meaning of the proposals, and posposals might be edited, split or grouped at this stage.
I move any “must deliver” epics into the “approved” area of the wall. Try to limit these to existing/carry-over commitments and executive mandates.
Assign a budget of dots/stickers/votes to each team member. People can then vote by placing the dot/sticker/vote on a post-it. They can use their votes in any distribution they want, so they could put all their votes on their biggest priority or distribute their votes. Seeing how team members assign their votes and how they allocate their budget can be very revealing of people’s priorities and interests. Don’t forget to vote yourself 🙂
Remove any epics that received no votes. Allow each team member to assign one additional vote.
Guesstimate the capacity for the planning period (weeks of work is a good level of estimation). Order the winners by vote. For each do a very rough on the spot scope and estimate (again a week is a good level of granularity). Do not record these estimates and DO NOT USE THEM as commitments. DO use them to determine how far down the list to go. Move a reasonable number of epics to the approved area.
Review dependencies of the approved epics and identify tasks to be filed and next steps for each. Follow through. When you set up a road map, board or whatever manifestation “planning” has for you, be sure to point out the effect of the voting on the resulting roadmap.

Warnings

Don’t waste time being participatory if you don’t need or want to; only be genuine. It’s worse to tell people they have a say but actually dictate than it is to just dictate and be done with it.
These kinds of approaches and cultures are not great for making deadlines. But that doesn’t mean they are slow. In fact, I would posit that the velocity and agility of participatorily planned teams is greater than command and control or scrum-negotiation teams. Particularly for startups or where pay is lower and thus you need alignment via shared intrinsic motivation, rather than carrot/stick compensation and corporate laddering.
Introduce and practice these things cautiously and iteratively. Always retro. I cannot say that enough. But as you practice and iterate, also learn the nuances and tools available to you to subtly manipulate the outcomes, based on your particular skill, personality and context. Be genuine. Respect the outcomes of votes and take input seriously. Don’t try to damn the river. Learn how to channel it.

Contending with contemporary methods in design

If you’ve worked with designers, researchers or product managers who’ve been educated in, or advocate for “user centered design”, you’ll know it is well worth researching and learning about this philosophy and the processes it advocates. If you haven’t, see this standardized summary and this video by way of introduction. The original, complete, user centered design process is quite full and nuanced, and like many development and design systems it is rarely (never?) fully and completely implemented as envisioned. However, many of its methods and ways of thinking are useful, even without full adoption of the entire program.

Below, are some thoughts on some of these methods (not the program as a whole) and the good and bad of them, and how to deploy them effectively.

One of the main related methods of user centered design is user testing. This is the most important thing you can take from this. Watch users use your product. There are services and firms that can help you, but even you (yes you!) can record and observe a user while they use your product. Don’t intervene, don’t let them see you. Then ask them questions when they’re done. It’s never not informative.

I love user testing, and have used, and advocated for it, since I learned about it. But it is focus grouping. It will reduce the risk of confusing or failing the user, but it won’t find a compelling use case. Just as a focus grouped movie is less likely to fail, but focus grouping is unlikely to turn a shitty movie into a hit. You still need the need discovery. In user centered design they advocate for a generative research and prototyping process to achieve this. Personally, I’ve never seen such a process uncover a need that cognitive empathy with a well developed persona could not. But obviously these methods have been quite successfully applied by some. It does provide a lot of evidence for needs, though.

Which brings us to personas. Personas are archetypal users that represents a defined audience or role in the system. Often these read like the product of a marketer’s imagination, and that is indeed their origin. Usually they come with some cheesy name (“The Megainfluencer”, “Soccer Mom”, and so on) and some demographics. Even when developed specifically for your audience, I’ve found these to be of less value than user testing. Often they are good for organizing and explaining the product or its user stories, especially in documentation, but less valuable for decision making, or actual feature development. There, they can help develop empathy, and also help give focus and reality to stories and features. But I’ve been involved in very few systems or contexts where rich personas were more useful than just simple names for roles and user types, and associated needs or stories. I’d also strongly urge caution if using personas without real training in user centered design or marketing, especially if the personas involve people unlike yourself. It is very easy for a well intentioned amateur persona to become indistinguishable from an offensive bundle of stereotypes that reinforce bias rather than develop empathy.

An Introduction to Jiko Kanri

When I was helping to grow mNectar I was lucky enough to work with Artem Gregoryan. A fine CTO, Artem was very open minded about process, and was very pragmatic, in that he didn’t care what systems I wanted to use, as long as good things got done. I did a lot of web research into “flavors” of agile. I needed a system that was effective with the particular team dynamic of an early stage software startup, where everyone:

is highly motivated
is high performing
is not rigid role oriented

This means process is about organization and mutual understanding, rather than command and control.

After watching hours of YouTube talks on software process, and reading too many “experts”, gurus, organizations and systems’ websites I thought, “I’ll just create my own parody system”. I decided to make a website that masqueraded as a non-profit advancing my process management philosophy, but it would only be a façade. An few slogans and clichés, some links to media about this I like, and an Amazon affiliate link (mostly for the irony of a non-profit with ads). Although I had learned a lot, many of these systems seemed largely hollow, like schemes or cults, not much more than could be summed up in a paragraph of text and a few slogans. I also used the site to play with ideas of camp software design and new technologies in css.

So what is Jiko Kanri, really?

A cultural program for high functioning teams of well motivated professionals, and a system for organizing their work. A set of principles for the system as a whole, and for the two roles (manager and worker) in that system. It’s basically a Kanban style queue model with a lot of Toyota quality focus ideas and some other bits of my personal agendas thrown in. I believed (and still do) that it is possible to organize and lead a team to do their best work, without being rigid and controlling. Jiko Kanri lays this out and forms a short, shallow manifesto of how I’d ideally work. And indeed, I have since been lucky enough to work in places where I’ve been allowed to put many of these ideas into action, to good effect, IMHO. I hope you laugh at it, but laugh because it’s true.

Check out the root page of this website (the one you’re on :P)

For much more, pease enjoy this slide deck, which gets into detail about what I was up to when I created the web site.

The Limiting Factor

In high school chemistry, my excellent instructor, Mr. Gleich, drilled into us the concept of the limiting factor. It was so counter intuitive. Why wouldn’t speeding up any part of the reaction not speed up the overall reaction? It made no sense to me and many others, but he drilled it in. He used analogies, exercises and demonstrations… eventually, even though it’s counter-intuitve, it was clear: only the limiting factor matters.

As a newbie PM, I instantly recognized the same math applied in many situations I faced. I had a product or milestone, a chain of reactions turning raw materials into a final result, over time. I wanted to know how long the reaction would take, and where to apply the catalyst. And I still think this is the key to optimizing any process. Reducing pain, playing politics, and playing favorites has their place in deciding where to put your energy, but the only thing that will really make a process faster is ruthless focus on the limiting factor, enabled by a clear understanding of the rates at each step. You need to understand what the slowest, least efficient step is, but also keep an eye that optimizations to that step are not offset elsewhere in the process. Although a full model is helpful, action anywhere outside the limiting factor is not. Know the whole system, but act on one factor at a time.

To give a concrete example, say you have an enterprise product that has a per-client implementation process. Say you want to increase the number of customers you can onboard per month. If your can make the install process faster and the IT training smoother, but the real blocker is legal sign-offs on the contracts, your revenue will not really budge. If legal can only approve 4 deals a month, the number of trainings you can do is irrelevant to your goal. Of coarse, after you get legal to pick up the pace, you might find those trainings are limiting you after all, but that is what iteration is for.

That’s a simplistic example, but this applies to things you might not normally think of as “processes”, but can be modeled and attacked this way. For example, revenue is actually the residue of a reaction. Your product/marketing/sales meeting the market atmosphere. If there is a slow reaction, a low revenue per unit of time is the result. If revenue is slow, or inert, limiting factor analysis can identify what part of your hoped for, theoretical, market reaction is not happening. Marketing message not landing? Missing a key feature? Pricing wrong? Lay out your factors and their rates. Then act ruthlessly to improve the limiting one.

Walkthroughs

I stole this idea, cause it was so good…

At Smule I worked alongside Kevin Sung, Kevin is a stellar PM and one of the sharpest people I’ve ever met. He had worked at Zynga, and learned the concept of the walkthrough there, which he spread to the other PMs at Smule. I immediately saw it’s immense value, especially before shipping major changes or new features.

Here, I’ll explain my take on the context, process, and benefits of a team product walkthrough, specifically for mobile devices, but really applicable to any complex software.

What you need

There are a few things your team and product will need to make the most of a walkthrough:

A set of user stories in an outline, or workflows for the features or product to be analyzed. If you have data which tells you common user flows and funnels, consider using those to write and structure your outline.
A pre-release build.
A collaborative note-taking document (at the Wikimedia Foundation we use something called Etherpad), but google docs and many other things will do.
The ability to steam a device screen (and ideally record) in a way the whole team can see.
A healthy team dynamic, and a team that can deliver and accept critique professionally.

The basic process

Gather the full development team for a product or feature in a room (physical or online). Appoint one person as “the finger”. This person will hold the device, and act as the finger of the platonic user or persona. This can be any person on the team. The device should be streamed (if the team is remote) or mirrored (for a room) and also ideally recorded for later review. Additionally a note monitor should be appointed. This person will write the PM and finger’s notes (as needed), and ask the PM to stop narrating if note taking is lagging behind the walkthrough pace.

The PM should begin to narrate the user’s basic motivations and desires, walking through the user story/ies to be analyzed. The finger is then responsible for actually finding and taking the desired action.

As this is happening the rest of the team are responsible for watching the stream and looking for issues. Notes and issues should not be discussed out loud (only the PM, note monitor and the finger should be speaking, by and large), but rather noted in the shared document. On the other hand ALL written comments and notes should be encouraged, be they bugs, useability notes, visual issues, brand standards, anything. Each function (UX, frontend engineering, QA, marketing, etc) should especially focus on their area, and attempt to look with fresh “user” eyes at their team’s work for the first time again.

At the end of this process, each team member should summarize for the team, their thoughts on the state of the app as they just saw it. Is it ready for release? Did they see any potential blockers? How do they feel about their work?

After this the PM, potentially in combination with team leads (depending on team size and product complexity), should look at each note in the doc and triage it. I usually keep it simple and do four buckets: blocker, follow-up, punt, ignore.

Blocker: the product cannot be released until this is fixed or remedied. I strongly recommend you file these immediately into your task management flow, to show the they are the most urgent, and came directly from the team’s efforts at the walkthrough.
Follow-up: the comment, note or issue seems relevant, but is too vague to be actionable. I usually turn these into personal to-dos, send a follow-up email, or add them to future standing meeting agendas (planning, standup, 1:1, etc).
Punt: the issue is valid but not a blocker or requiring immediate action. File and forget.
Ignore: the note is not valid, actionable, etc.

Key benefits and points

Besides the direct benefit of the issues found and improvements that result, this process has a number of other benefits for the product and the team:

User oriented: The whole process reinforces the primacy of a user and their story, increasing user empathy, and encouraging the team to think of their work as a whole experience.
Quality reinforcing: quality is everyone’s job, and everyone has their own taste. This process focuses everyone on the quality of what they are about to put out, but allows everyone to examine and express their opinion in their own area. It also provides a way for introverts and people who are better in writing to give feedback about the product.
You do it together: The whole team that delivers the product should participate. The line engineers, the ops guys, customer service, the marketing folks, anyone that shapes or needs to know this product or feature should participate. This encourages a sense of collective ownership and the summary reviews can be excellent ways for functions that may not normally meet to hear directly from each other.
Reality-based: like writing a term paper, it’s never a good idea to review your own work. Looking at each other’s work brings a dose of reality to the editing and iterating process. False impressions and misunderstandings clear up quickly in the light of a shared experience.
Follow-through: I cannot stress how important it is follow up on all legitimate comments and notes, especially the first few times through the process. If the team thinks they’re listening to you narrate the world’s boringest livestream, they will disengage and the time will be wasted. Consider their feedback seriously and take action where needed.
As Jeff Smith, CEO of Smule once (justifiably) told at a PM: “I don’t care what the numbers say. USE THE FUCKING PRODUCT”. This process forces everyone to see what it’s like to use the fucking product. That can only be good.

Debt

One of the perrenial topics at any software org I’ve been in, big, medium, and small, is “tech debt”. How much we have, how much we’re generating, why it’s the root of all evil, how it’s a bullshit engineer excuse. It’s a very popular metaphor, if often poorly considered.

So, let’s look closer at the metaphor, itself. The idea is that there is some level of quality, elegance or completeness that software should be at. However, it is in use at a lower level of quality, elegance or completeness. The work (usually measured in man hours, abstract points or development cycles) to move from the current, to the desired level, is the “tech debt”. You can pay it down, or keep racking it up. You can estimate how much you have. It will naturally grow over time, unless payments are made, akin to compound interest. Oddly, it’s also a kind of “friction”, which “slows” development, causes bugs and makes work less enjoyable. But, let’s set that aside for a moment, and talk about the implications of the debt metaphor.

One implication is that PMs, as the owner of the product with the debt, need to understand how to be comfortable with their debt, and how to manage it properly.

In the late capitalist economy it is not desirable to have no debt. Governments have major debts and will never pay them down (only forward). Citizens are heavily incentivized to get mortgages. Students need loans to make more money in the future. Eight in ten Americans are in debt, and despite what moralists say, that’s not a sign of personal flaws, but a natural result of a system where debt is advantageous. I would argue this all applies to software and technology as well. Being debt free means you passed up an opportunity.

Why? Because debt is moving growth forward in time in exchange for risk. If you can afford zero risk, then yeah, never have tech debt. Building nuclear submarine hardware drivers? Please have no tech debt. But most of us can afford some, managed, risk, and we can often exchange it for growth.

This applies to software very directly. Ship with a few features incomplete? You add risk of bugs, or that a missing feature would have been key to market acceptance. Running on an old, poorly maintained server backend? Risk of mass failure, data breaches, or dev ops revolts. But the flip side of cutting scope short is shipping to meet a sales opportunity. The good side of the old backend stack is that it works, costs nothing to maintain and is a well known quantity.

This is how to “manage” your debt load. Just as you try to fairly consider stakeholders input to come to the best solution, you can, for your team’s goals, step back and look at the benefits and costs of your debt. How bad are your risks? How great is the potential growth moved forward?

So if debt is useful, as long as it’s managed and risk is okay, why do teams, especially technical and design teams often view debt as only a great negative?

I would posit that it’s because of what engineers, and others, mean by debt. They deal with it every day, while for the PM and management it is more abstract, with benefits. But there is a pain to this very productive jargon, that they deal with in their lives. The reality is, they don’t like or understand their own previous, or their predecessors, work. Or they weren’t given time to do something the way they wanted, or as completely as they want. Or they need to refactor based on added features, or functions, or new models, or new best practices. They want something that was done changed, or they want to change something that was left undone. Sometimes they are right. If business imperatives, or you, are overloading them, debt will accrue. Risk will mount. And it will slow things down, and suck for them, and eventually your users. But how much debt to carry, and how risky it is, is for you to manage.