Process – Page 2

Unknown Unknowns

I fear the day that the MBAs and people that would have become “financial analysts” in the late millennium fully take over the culture of software product management. These are fine people, but they are abstract risk managers and value optimizers. They could be structuring financial instruments, selling jars of pasta sauce, or running software systems with almost identical approaches.

That said, my favorite framework from the finance industry that serves me every day as a PM are the concepts related to risk. Debt, insurance, investment and even team management are often about the accurate evaluation and management of risk.

The future is unknowable and we’re always dealing in probabilities and manipulating the likeliness of outcomes, not guaranteeing them. How do you handle this as the person most responsible for delivering success?

For any major undertaking, it’s important to think through and spend time on likely threats to the project’s success. But that only helps with the known unknowns, what about the unknown unknowns (to quote the wisdom of war criminal Donald Rumsfeld)?

Even when you don’t know the exact cause, it is still possible to manage vague, generic risk. Unknown threats generally come from a limited set of source types. The most common disruptions, in my experience, are the hidden stakeholder and the implicit requirement, both usually discovered late in the development process.

The hidden stakeholder means just that: it becomes clear that there is a function or person who might kill, block, or otherwise limit your success. The implicit requirement, similarly, is a story, feature or capability that limits or threatens your success, which you failed to identify during research and planning.

Think about what you would do to prepare. You’re gonna get hit by something: keep your head up and at least see it coming. Should one of these manifest, triage dispassionately: is it in your control? is it really a blocker or problem? Some things, like personnel losses and context changes should be accepted and accommodated. Some, like exec meddling, team stalemates or nice-to-haves becoming blockers, can be worth fighting to overcome. Some things, like technical risk, dance in the grey area between the two.

Of course, the real solution I always recommend agile development processes, and indeed agile thinking in general. The answer to not knowing the future is just to embrace that things will change, you will learn more and change is as much about opportunity as risk.

Data Games

One of my least favorite kind of PM compatriots are those who insist that they are purely data driven. Like all zealots, they’re often tiresome bores, and while there is a lot of truth in what they advocate, their smugness and certainty is off-putting. But, of course, numeric measurement is useful! So here’s a few downsides of shallow quantitative methods, as a dose of skepticism for all you quant advocates.

I think the greatest downfall of data driven approaches is picking the wrong number to build a goal around. If you work with smart people, even the best intended will game a simple numerical target, when selected without care and consultation. In one of my favorite stories about this, a company decided to set sales quotas by weight of items shipped from the warehouse. After months of record setting sales, accounting realized the weights shipped didn’t match the actual revenue the invoices reflected. The sales people had paid off the warehouse guys to add bricks to the shipments.

Another pitfall is not actually understanding whether the KPI you are tracking really means what you think it does. If a number is a “proxy” or “simplification” of some more complex behavior, beware! Always understand what the numbers really represent, not what they have come to represent to the team, especially when working with a mature product. What events trigger them? Don’t assume something labeled “conversion” is actually when revenue is generated. Look past the numbers to the underlying activity.

The next step is to move beyond description to analysis. Always be looking for the story. Why a number is, not just what it is. What does it mean? Being data driven doesn’t mean putting graphs in your decks and having dashboards. It means using quantitate data to make decisions, and understand how people use your product. Explore your data. Don’t just refute or prove theories with it, discover hidden failure points and identify new opportunities. If you’re lucky enough to have a good analytics system, get immersed.

And woe, beware the data driven emergency! I have seen many many times an urgent alarm is raised based on a single chart or number. Something is down, something is up, this looks way off. I would estimate that 90% of these end in one of two ways: a bug in the data, or a misunderstanding/change of definition. Analytics are tricky systems, and events and calls can easily move or change implementations without everyone knowing. Before you freak out, eliminate these options.

Numerical data is not an inherently superior or more honest. It’s as easy to lie with numbers as stories. It’s as easy to have bad analysis as bad taste. Always be scientific with data when you need to know the truth: taking measurement without prejudice and being clear eyed in your analysis. But be lawyerly with data when you use it with others. Pick and choose the evidence that best supports you, not lying, but treating the data as secondary to the narrative. In the end, I believe, data is there to build and support the narrative, not t’other way round.

Everybody Wants to Rule the World

I happen to like modern and conceptual art, when it’s good. But I’ve never been at a busy modern art museum and not heard the clichéd comment “my kid could paint that”. (My answer usually being: I’d like to see that.)

The medium of software is, similarly, one users tend to criticize from a place of “knowing better”. This tendency extends even to those who make software. “If we just…”

Everyone wants your decision making rights, even if they don’t know it. In the next few essays I’ll talk about various typical stakeholders and how to interact with them in a productive and empowering way, while also protecting your prerogatives and role as decision maker.

Before we get into specific relationships, I wanted to call out some commonalities that hopefully illustrate what I mean, and help new PM or interested outsiders understand how this kind of leadership can be done.

One thing that separates a great PM from an okay one is that they understand that their job is not just setting the agenda but setting the tone, and team narrative. Is the team a successful release machine, delighting users and hitting KPIs? Or is it an abject failure that builds buggy shitware and is about to be re-orged into oblivion? Between these poles, there is a lot of complicated reality. A great PM will shape the team’s reality. Not though lies, withholding and manipulation, but through emphasis, tone and self-certainty. In discussions and meetings be real, but also determined: cynically optimistic.

The most obvious way to be the team’s leader is to be the person who decides, or decides who the decider is. If there are disagreements between functions or teammates, or you don’t need to make the call, always state clearly who has say. Do the same when out-of-office, or unintentionally neglecting a situation. Don’t let it hang: delegate. Weirdly, the best way to protect your prerogative is by delegating it frequently and explicitly. If you don’t make the decision, decide who does.

I personally value decisiveness and determination very highly, and although they can shade too easily into arrogance and stubbornness, such is the case with any virtue taken to extreme. One way to avoid this extreme, but maintain decisiveness, is to embrace negotiated decisiveness. Let the negotiations run free, and let discussions happen. Then be the one that ends them. Then, once they are ended, record that decision and maintain your determination to see it carried out, until new information is available or risks manifest. Again, this kind of leadership is not, at core, about seeing your meme win (“getting your way”), but about having say over which memes are allowed, and how they win (“being the decider”).

Finally, remember, when making decisions and considering the sides of an argument or political situation, that surety doesn’t equal correctness. The people who are the most determined are not always the most correct or well intentioned. If you want a career in “authority-less leadership” you have to be able to not give in to bullies and blow hards. Let them blow. Remember they will get mad when they don’t get their way. Remain calm, and practice benevolent determination.

Keeping sales and marketing in their place

This is one of a series of essays about how to relate to common stakeholders. Here, I’ll provide some tips for working successfully with revenue people, like marketing and sales.

I have never worked with marketing or sales people that didn’t want some or many features and products I did’t have or ever plan to have. Many of these requests came with promises and guarantees of success, revenue, friendship and more (though I was never offered a bribe or kickback, sadly). It doesn’t mean the product is deficient, or you need to chase the supposed opportunities. Triage them reasonably, and individually, but just know that the revenue people always want more.
Similarly, these functions always want or expect things on impossible time frames. Especially in large or silo’d organizations, where these people often have little concept of the work needed to deliver on their promises. Again, be cynical but optimistic. Gauge the risk, and if you can’t meet their timelines communicate that as soon as you’re sure of it. Get the pain out of the way.
A corollary of the above is that these are the stakeholders (besides execs) who always want hard deadlines, and are therefore usually the most adamant about thinking about things in waterfall type processes and phased, scheduled, commitments. Do what you need to accommodate them, but never let their need for “dates dates dates” become a thing in-and-of-itself. Deadlines are for customers, press, partners or revenue, not because sales thinks you should have them.
Sales people are like customers. Listen to them, yes, but pay attention to what they really say and do. Go on sales calls. Go to conferences. How do they talk about the product(s)? What do they really focus on? What do competitors focus on? What is the zeitgeist they’re selling in? Study them in their native environment and discover their true needs.
Like bonding with engineers over programming languages, one good way to bond with sales (and marketing) is over competitor intelligence. Talk about your competitors, their product, their silliest shortcomings or recent flops. Be genuine and show them you know what they’re up against. It will help them open up about what they think of your product, and focus you on your common enemies.
Let marketing and sales own public terminology, but listen to the words they actually use — always participate in naming and major branding decisions, if possible. Names matter.
Just because they bring in the money doesn’t make them the boss. Beware tolerating toxic sales people or allowing them to set the product roadmap. Being pushy, or good at sales, does not make them good product people. Additionally, unlike engineers, in many industries they are generally low skill and replaceable. Be respectful of how vital they are to your livelihood, but they are, more than other functions, best kept contained in their domain. Visit them, do not let them in your domain too often.
If you are selling a new product, or are in a startup doing enterprise, or any kind of in-house sales, and your first sales person is failing, quickly move on from them. As stated above, engage with the reasons for their failure to iterate on your product, but never let a lone salesperson determine the fate of a product. Now… if your second salesperson also flounders, you probably have some product market fit problems. Or your product might just be a piece of shit.

Keeping power users in their place

This is one of a series of essays about how to relate to common stakeholders. Here, I’ll provide some tips for working successfully with power users or internal user stakeholders.

For a while I liked to watch small-business-makover reality shows. In these shows the hosts, who are successful entrepreneurs, sweep in and yell at a small business owner, remodel and fix any simple errors and get hugged. I found these shows about barber shops and hotels, bars and restaurants to be informative in the ways of business, entrepreneurship and the elements of success. For bars/restaurants, one of the most common issues was older establishments that were long overdue for an update. This tension between keeping regulars happy and keeping things fresh to get new customers coming in is remarkably applicable to the issue of keeping an audience of users happy, while also trying to make changes to bring in new users. There are no easy answers in restaurants or in software, but there aren’t TV shows about power users, conversion funnels and MAU decline, like there are about restaurants. Not yet.
Like people that rep themselves in court, or self-diagnosing a medical condition, it’s a bad idea to let the user define their own product roadmap. They lack the needed perspective. Most people understand this, and will either defer entirely to your team or will work in whatever way you want with them. But there are always a few that equate using a product with owning it. Like the fans that nitpick every change from a comic turned into a movie, they equate their attachment and loyalty to lay claim to being not just critics but owners of ideas.
BUT it is super important to genuinely listen, not to their solutions but their needs. Don’t take them for granted, and in particular keep your ear out for change. New complaints, new attitudes, new usage patters, these are your core community speaking.
Or, sometimes, just give them what they want, so they shut up. In some cases, if a task is small and inconsequential, even if it is totally non-strategic, it is well worth doing. Sanding down the edges of software goes a long way with people who have to use it a lot, and it makes them know they are valued and heard. Find the simple annoyances and fix them.
The later in the product lifecycle the more important this balance becomes. As growth slows, learn how to make user-priroitized changes and maintenance a core of your process. It takes different norms to fix complaints and keep things going than to discover value and build new features.
My spectacularly insightful co-worker, Anne Gomez, reaches out to new PMs at our organization when they are, inevitably, confronted with the intensity of our power users, especially when you do something they don’t agree with. She tells them about an early episode of Parks and Rec, the first of many where Leslie is harangued by irrational townsfolk. Leslie’s response is this:

Always keep that in mind when strangers and customers yell at you, call you names, and denigrate your teams work in reviews, forums or whever the pitchfork wielding mobs of your platform gather. At least they care. It’s much worse if no one gives a shit.

Keeping designers in their place

This is one of a series of essays about how to relate to common stakeholders. Here, I’ll provide some tips for working successfully with designers.

The relationship between the designer(s) and pm is the determining factor in user experience. Their mutual understanding of the user is the software’s understanding of the user.
Hopefully, it goes without saying that design encompasses more than how the buttons will look or what font to use. UX is not visual design. But it is metaphors, aesthetics and taste.
If you have a good designer let the designer own the experience. Just set the stories and the priorities and let them go. If you have a junior, outsource, or less talented designer, still let them go first, but expect to edit and iterate a lot. If you do wireframes to convey the story or experience you want, either do it very low fidelity (whiteboard, etc) or give screenshot examples. If you’re doing high fidelity mock ups or prototypes, you’re a designer. Thats cool, you can be both, or may have to be, but those are design thinking tasks.
Good, compelling, design is about a single vision or aesthetic shining though in a collaborative medium. Even in software, it’s easier to understand and transmit emotion via a single designer than a committee. If your product has had many brand, design or designer changes over time, consider the potential value of a normalizing effort to unify the look-and-feel.
Designers are often emotional; creative people need to be passionate, but can also be dramatic. Just accept it. Don’t over-react but don’t treat their feelings as invalid or unreal. They are very real to them.
Many designers, especially the young and inexperienced (or lazy) will give you one design and say “here’s the design”. Make them show their process. Like checking in source code and breaking down programming work into milestones, designers should be able to share their ideations, helping the team understand not just what they are proposing, but how they are got there and why they are not proposing other ideas.
In complex software designers are often working on features or interfaces in isolation. It’s vital the PM work with design leadership to keep the holistic user view and big picture (how interfaces interact, patterns/metaphors/components consistency, and building shared intuitions) and most of all, priority. Design is prioritizing things visually and in terms of the interactive space (how much space to give to each potential user action, what gestures will do what, which actions to make easy or hard). The clearer you articulate your user’s priorities and hierarchy of needs to the designer, the clearer that should come through in the interface. Do the designs priorities match you’re users priorities?
Don’t let design determine the roadmap. Design is about how the user experiences the product. Product should always own what the team focuses on and why.
Provide an incidental creative outlet (team schwag, internal logos, UI of internal tools). Ask/expect them to own the visual space of the team, in whatever form.
Know basic design jargon like you should know tech jargon: visual hierarchy, wire frame, high fidelity, evaluative vs generative design research, what the hell is an affordance?

Keeping engineers in their place

This is one of a series of essays about how to relate to some of the most common types of stakeholders and teammates. Here, I’ll provide some tips for working successfully with engineers.

Know some shit about technology and programming. For real. Not a weekend bootcamp or a few YouTube videos. If you didn’t take programming in school, take a class online, and build something real. Simple html/css/js web sites are really easy to build, for example. One of the best ways to connect with almost any engineer is to have opinions about programming languages or tech fads. DON’T fake it, but also knowing what is hard for you, what you like or find cool in tech is great small talk and icebreaker fodder.
The most important thing the PM can do to influence an engineer’s motivation is to give them context and provide reasons why. Explain the politics, if you have to make an “exec mandate” decision. Give them the data behind your decisions. Always be willing to share reports and product docs with them.
Even in the most “top down, corporate controlled” culture, you must remember that software engineers are skilled, and often highly in demand. They are not your minions to build your beautiful visions; they are your skilled partners.
Don’t let them refactor without reason. If engineers are asking to refactor or rewrite software a lot, get an understanding of why, how long or often this is likely to go on, and if there are other factors in play. One CTO co-founder of mine literally banned engineers from saying in stand-up that they were “re-factoring” something as their task that day. They had to explain what functionality was being changed and why. That seemed to result in a lot less refactoring, some how 😉
If you have talented and valued engineers and they reject process and administrative tasks, don’t fight hard. If you can, simplify and do it for them. if they still reject participation and process, become a broken, polite, but insistent record. If that fails, escalate.
Always treat standup as not optional for the team (including the PM). Showing up and participating in standup is the definition of being on the team. If you don’t take it seriously, you don’t take the team seriously. Especially for remote people or teams. Don’t ever let engineers skip stand-ups regularly.
Never think of your engineers as interchangeable. Engineers have unique problem solving styles, skills and strengths. Managing a development team is like managing a baseball team. You can’t make a pitcher a 1st base slugger. Or in an orchestra, if you prefer a non-sport analogy, you maybe can get a viola to play violin, but if you need a French horn, there is not much they can do for you. Its not like the roles are 100% rigid, but players have some roles they can do, some they excel at, and some they can’t do. Know what your engineers are good at, what they like doing, and try to incorporate that into your planning and management.
Every engineer has a multiplier. The multiplier is the difference between how long an engineers estimates are and how long their work really takes. Rather than point/velocity systems, I prefer to use these multipliers for planning. Basically when an engineer “takes up” a task or needs to size it up for planning, I ask how long it will take. When I first work with an engineer I keep track of how that estimate relates to the outcome. After a few weeks you should be able to pretty accurately plan delivery (modulo tech risk, scope change, etc) from the engineers estimates times their multiplier. I’ve worked with engineers who’s multipliers have been from 0.75 to 3 or more. Don’t try to get them to be more accurate estimators, and don’t flaunt you’re multiplication in their face. It could seem like you don’t trust them. Let this be one of those subtle arts of PM’ing.
Some engineers, especially young, ambitious, ones, might be keenly interested in, or vocal about, product or design decisions or plans. If you can safely involve them, you should try to do so. If their ideas are bad, or their “product orientation” is detrimental to the team (rather than helpful, which it can also be), be direct about it with them. On the other hand if an engineer is not interested in business context, product theories, or the why of their work, and just want to work on task, respect that and leave them alone. The outcome is what matters, not the method.

Isn’t this civilized?

This is gonna sound weird, but have meetings over food sometimes. To start, here are some useful “meetings” that are best with lunch, coffee or drink:

Cross functional lunch groups – Lunch groups are pre-scheduled groups of co-workers (who might be randomly matched) so that people can get to know co-workers they may not work with directly. Icebreakers help, esp if the group has a lot of introverts.
Monthly happy hour – For those that need to blow off steam and connect over a spirituous beverage. Just limit yourself to one.
Outing – Go somewhere fun together. Don’t try to get something directly productive out of it. Just play and enjoy.
Beverage run 1:1’s – The best way to connect is over a cup of caffeine and sugar. Boba is good too.
Planning and conspiring in small groups over food – The late night pizza driven session is the canonical example, but it can be healthier than that. Need to bond and focus with a small group? Ordering in food takes one distraction off the table, brings people together and refuels their mind.
Some types of brainstorming – Depending on the materials and process a little mental lubrication, and a celebratory “free wheeling” atmosphere can lower creative inhibitions. Be careful of HR violations though.

Other tips for this kind of sociable meeting:

Meet in inspiring places. Free museums, public spaces or libraries nearby? Get a new context. Also useful sometimes to build a “regular” place or habit with these, as that can add to the sense of being an in-group and bonding.
Have fun together without being a partay animal! Never ever drink more than your team.
These events are, at their core, to remind people of their shared humanity, encourage social bonding and to build empathy. They don’t need to be directly productive. Stop checking email and IM and listen to each other.
These approaches are often as, or more, effective as “team building” programs and systems, but without the consultants and binders and worksheets. To start: just be human with each other sometimes.
If your team chemistry is bad, or a team member is toxic, this won’t work. But it will help you diagnose that in your attempt.

Sharing a meal, playing a game or just doing whatever let’s you be together, but not working. It gives you and your team members a reminder to respect and understand each other as human beings, not just functions. When tense moments flare or all-hands-on-deck emergencies arise, this can pay off immensely. A shared sense of humanity can make all the difference in how a team works.