jtminor – Page 3

do not doing

One of the biggest mistakes I see PMs, and people in general, make is their bias towards action. I don’t come to my job with the protestant work ethic and preference for action in every possible situation. Instead, I find much of my thinking about labor/effort better reflected in the Dao De Jing. Among it’s messages is to act as naturally as possible, to spend effort on identifying the flow and going with it, rather than activity for its own sake. This is sometimes boiled dow to the translation “do not doing”. In product management, I apply this to mean “sometimes it’s okay to CHOOSE not to do something as the best strategy”.

Resist the temptation to view work and activity as a valuable end, in-and-of itself, or as the solution to all problems.

This kind of “inactivity by choice” can be the right strategy in many situations, here are three examples:

Sometimes don’t build, repackage

Often, in software companies the temptation is to keep building new things. There’s a genuine need to deliver new features and updates every cycle for sales and marketing. And we’re paying a lot of engineers, we better keep them busy with interesting work! But I have had some of my biggest successes not with new things, but with old things applied and packaged differently. Often, the desire to do something new is because the existing product is not gaining the market or stakeholder acceptance expected. But if you do your research and listen to what users are saying, you may already have the solution with very little technical work. Instead of 6 months developing a new product, a change in interface emphasis and new marketing story may sell just as well.

don’t overreact to Analytics Noise

I worked in a very data driven organization with a hard driving (but quite effective) chief executive. The PMs and C-levels lived in fear of the email with a screenshot or link to a dashboard: “this number was down, do we know why?”. Many of these were valid queries, and they occasionally uncovered genuine issues. But more often than not, it was an unexplainable short blip, analytics bug, or most often, just a misunderstanding somewhere. And this chief executive was a genius (really). Most of us lesser mortals have an even lower “spot-a-real-problem” hit rate. That’s not to say you shouldn’t care or monitor your numbers (quite the opposite) but also learn how much noise and error exists in your context, and learn to triage these numerical mysteries as you might with bugs. Develop a methodology and intuition to know when to take action, and when to do nothing.

sometimes pass on an opportunity

In dealing with sales, or functions driven by month/quarter bound commissions or bonuses, there is a constant pressure to deliver something for a client or timeframe that does not account for your team’s reality. As with a marathon, just because you can run a 6 minute mile, doesn’t mean you should, if you want to finish the rest of the race. Asking the team to work nights and weekends better pay off, at least more often than not. Rearranging your roadmap for a marquee client can work, but it can also become a golden goose chase, giving the team whiplash and undermining any strategic thinking or product theories. Too many start-ups have been destroyed by taking on too much business or chasing a series of mega-opportunities before they were ready. Sometimes the best answer to inbound business is not “YES!”, but “not yet, but let’s talk”. Don’t go bankrupt “screening” your customers, or rigidly maintaining your scope in the face of product failure, but, also, be willing to be the leader at the table that says, “no, let’s not put in this in our sales proposal”. (Of course, a compelling “and here’s why…” should follow).

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.

Showrunners

Software product management, by and large, descends from consumer goods product managers. The idea of a wholistic product owner, market analyst and in house success engineer comes from Procter and Gamble and other consumer brands. Except in games. In games they are called Producer, in an analogy to movies. Essentially the same kind of job, both in the same medium, just different genres. Weird right?

I believe this is a result of software being a relatively adolescent medium, which borrowed pre-existing metaphors, jobs and work patterns and gradually grind them into the right shape for software. So, yeah, being a software PM is like making a consumer product, or even a b2b product, not that different from any other business. But it also is like being a movie producer or director, leading a collective commercial creative endeavor to deliver a media experience. I want to throw a third out there: the show runner. http://www.showrunnersthemovie.com

Show runners are the driving force and final editorial voice of modern TV. The prestige TV renaissance, with its serial dramas and long form complex narratives, is all made possible by show runners. Like PMs they combine leadership, creative strategy, and ultimate ownership of success. Sound familiar?

So what? Why does it matter? Because, as a similar, but different job, show runners have things to teach us: tools and patterns we could import, heroes to emulate or failures to avoid. But not just show runners. Cool as they are, my larger hope is that as software development evolves and continues to mature and that software Product Management will become its own thing, even if it borrows its names, and its tools, from many sources.

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.

A Matter of Taste

Steve Jobs once famously said on 60 Minutes that Microsoft had no taste and its products were unoriginal and culture-less. In his usual, insightful douchebag, way Jobs was articulating an idea that I think is paid lip service, or even attacked, but rarely engaged with in a meaningful way. That is, what is the role of “taste” in a software product’s success and a team’s process? What is taste, anyway?

First, I take taste, as used by Jobs here, to mean an understanding of what users want and expect, and how to make things that are not just satisfying to their needs, but appealing to their senses. Tasteful things affirm their owner’s sense of self-identity and make an emotional connection with them, over and above the thing’s basic utility. This talent/skill is often derided as hopefully squishy, unscientific, qualitative and arbitrary. But, I would argue that is a misunderstanding of taste by those who don’t have any. Taste doesn’t have to be a golden sight that some people have and others don’t. Or something that is so unpredictable as to be anathema to risk management. Taste is merely a predictive skill. One that, yes, some people are more talented at naturally, but which is not some magical, ineffable, quality. Just as antique experts can get better at predicting auction value, or top chefs can sometimes predict which new flavor profiles critics and diners love. It takes stepping back, doing a neutral analysis and introspection of your work. But even more importantly of your product peer group. Develop taste by practicing thinking “what do I like about this and why?” Develop it by seeing what really sells. Develop it by measuring feedback and understanding audience trends. It’s not some artsy fartsy nonsense. Learn what you like, and what others like. You’ll never be right all the time, but you can get better at it through focused intention, and attention to detail.

Most of all, I think this quote plays into the theory that being a great PM is a craft. Making something carefully, thoughtfully, that’s not just useful, but in some way beautiful, touching or meaningful. The kind of object or experience people will collect or remember. To have good taste is to know what will be compelling. Not just on first use, but in a way timeless, as much as software can be. Build your intuition for what is a flashy trend, and what is a good new paradigm that will be around for a long time.

Finally, this quote reminds me that, although I’m not a designer, aesthetics matter. What your design says to your users speaks louder than the copy on the screen. If you are building software with user interfaces, design is not an afterthought, or coat of paint on the machine of your engineer’s code. It is the thing that separates Apple’s best iPhone from Microsoft’s worst Zune. The Zune played mp3s fine, but it was in bad taste. If you’re not naturally a visually artistic person, that’s okay too. Hire one. Or work to develop your taste. Take a drawing or photography class. Go to art museums (especially modern or contemporary). Ask your designers about the designs they love and why. When you see something that you think is beautiful, don’t just pass it over. Stop, think, introspect. It’s not a magical blob of irrational emotional noise, untamable by analysis. Aesthetics are not random, there are patterns and you can learn them. And even more fun, you can feel them, if you care to.

So give taste a chance. Embrace your own taste (or acknowledge your lack thereof) and always work to understand not just what will help people, but will move them.

Steve Jobs is not my hero.

Many people I talk to think Steve Jobs is like the best technology product leader of all time or something. A hero of product vision and leadership, and a unique visionary for product managers to learn from. And don’t get me wrong, I agree Steve Jobs was a product genius, and anyone can learn much from him. But he was not a good person. He was cruel and selfish, grotesquely greedy and ruthlessly ambitious.

I wish another product visionary, CEO and uniquely successful technologist, who also died tragically young, was as well known and admired.

Satoru Iawata of Nintendo is my hero.