Company Celebrations and Indirect Incentives

By now it’s well known that the most reliable way to achieve productive collaboration across an organisation is to ensure that the incentives for each team are aligned. If we all want the same thing, we can all work together.

Often though, the focus is on direct incentives like compensation and promotion. What we talk about less frequently are indirect incentives like praise and recognition. Compensation and promotion are formal rewards handled by HR and so (hopefully) intentionally considered. But indirect incentives like praise and recognition are informal and ad hoc, and so often escape scrutiny. This can produce unintended results.

Think of it like this: what does your company celebrate?

  • If they celebrate moving business metrics, your product org is more likely to ship hacky, MVP-like solutions that achieve a result but leave product and tech debt and a less-than-ideal user experience

  • If they celebrate feats of engineering accomplishment, your teams are more likely to spend time on complex technical projects with unclear business value

  • If they celebrate slick user experiences with wow-factor UI, you’re going to be slower to ship and learn because implementation times are extended

From an org-perspective this is bad enough, but it’s even more problematic for the IC if what their manager celebrates is different from what the company as a whole chooses to recognise. If your company celebrates metric pushing but you’re in the design team which celebrates slick UI, you’re going to find yourself arguing with your product manager and engineers who keep pushing you to have a more stripped down solution.

The onus then is on leadership to be very intentional about what they celebrate. In the same way that we’ve learned to save our praise for achieved results rather than shipped code, when a product manager in your team tells you proudly that their A/B test lead to a substantial increase in conversion, challenge them on how they can get that experience shipped with a delightful user experience, built in a scalable way, that maintains the great conversion impact.

Back Yourself

Talking to a new PM recently that was having a hard time because they had to make a decision but weren’t sure about the approach. They knew what they thought was right, but were getting lots of “what about this other thing you haven’t considered?” type feedback.

It’s easy to be on the sidelines and say “but maybe this other thing will happen”, but much harder to be in the chair making the decision.

The truth is that as long as you have considered the reasonable possibilities and can justify your decision, that’s all that matters. There is no perfect information, and you shouldn’t be scared about the ‘told you so’ comments that might follow if the result of your decision was not a good one.

Get Involved

One of the most common complaints I hear from designers I know is that they’re not involved enough in making product decisions. The product manager - hopefully in collaboration with their partner engineers - calls the shots on what the roadmap will be, and design’s sphere of influence is limited to specific functional details of the feature.

This must be extremely frustrating for the designer! If I were in their shoes I’d hate it. Unsurprisingly, the design leaders in the team will want to change this pattern, and will advocate for design to make more of the decisions. But so often they go about this the wrong way.

You often see design leaders working with their teams to create ‘design roadmaps’ or ‘UX visions’ for the product. They are trying to plant a flag to say: “here’s what we think the future initiatives should be”. They expect that the pendulum of decision-making power can be forced to swing away from the PM and towards the designer. I’ve never seen this work.

Trying to propose alternative visions or roadmaps is the wrong approach because it sets the situation up to be one of disagreement; “I believe one thing and you believe another, let’s fight to see who wins”. Regardless of whether or not you win the argument, you’re only going to be left with increased tensions and bitter feelings.

To me, this is a failure of the design leadership. They are focusing inwards on what they feel they can control (running workshops with members of their own team only) rather than doing the hard work of engaging outwardly.

The people best qualified to make the decisions are those that have the most information and are closest to the problem and the work being done.

My proposal for any designer that feels left out of decision making is to get involved with the work. Get close to the customer problems, get close to the engineering work, get close to the realities of the business and the problems to be solved. Get close to the product manager.

Design leaders will not empower their designers by isolating them from the rest of the work. They need to get involved.

Reducing Product Risk and Removing the MVP Mindset

Good post from Casey Winters:

What is the right way to build products? Earlier in my career, I would have told you everything should be AB tested, and that you should build only as little as you need to validate a hypothesis. Every problem should have user research involved at the beginning, aligned on the problem instead of just validating or invalidating solutions. Every key result should be outcome based. Every engineer, designer and product manager on the team should be involved in defining the problem and the solution. These are all good ideas. However, once you add enough of these “best practices” up, it reads kind of like those articles talking about the morning habits of the most successful people in the world. If you actually try to follow all of those habits, it would take you six hours a day and cost a lot of money.

In particular, his post is focused on how many PMs reflexively reach for the MVP framework when building new features, even though it is often not the right approach for the situation.

I have definitely been guilty of this!

I often bias towards all new work being a ‘V0’, to being the hacked together, to being the minimum necessary to get to some value. The reason this is so often my bias is - as anyone that’s ever worked in software knows - that things always take longer than you expect, and so if you can limit the size of the project you leave yourself with more buffer for delays. Basically all projects have (let’s say) 30% more work than you anticipated. This is why it’s better to keep your projects short: if you keep the scope down to what can be delivered in 3 weeks, adding on an additional week in delay is not too painful. However if you had a 3 month project, that extra month is going to hurt...

The other benefit of the MVP framework is that the less you invest in up-front work, the less you’re risking in case your hypothesis is wrong. This is an argument for biasing more towards the scrappy MVP when you have higher uncertainty. However if you are confident in your hypothesis (for example, because you have prior evidence), this is less important.

For ideas you’re confident about, this is not to say that you do not need to work in iterations - you do! Shorter iterations leave less opportunity for unexpected problems to arise. It just means that the purpose of your initial iteration is focused on actually delivering value rather than proving a concept.

A Good Principle is Only Good if it’s Opposite is also Good

Recently I’ve been thinking a lot about ‘principles’. Almost all organisations have some set of ‘core principles’ or company values prominently displayed on posters around the office but (probably) infrequently referred to.

The point of these kinds of principles is to guide how you as member of the organisation should behave and make decisions in a way that is consistent with your colleagues. When you arrive at a decision point with multiple reasonable options, you need a framework to help decide which of these is the most appropriate. It is at this point that you can apply the principles.

This is all well and good (ahem) in principle, but in reality a company’s core principles are often treated cynically by its employees. The problem is that most of the time these principles are not helpful. They are too prosaic and catchall, leaving no edge on which you can make a decision. How many companies have a core value that relates to ‘serving the customer’? Almost all, surely - but that is not a valuable principle because it is a truism. No one could possibly disagree with ‘serving the customer’ and so it provides no value.

Want to make your principles actually useful? Make sure that the opposite of your chosen principle is itself also a good principle.

Remember: the point of these principles is to help us make decisions, and therefore they have to pick edges that will guide us down the most appropriate path even if (especially if) all routes look reasonable.

Some examples of product principles and their equally reasonable alternatives:

 

Our product should be easy to use the first time you try

Our product is tailored to the power user

We value attention to detail and getting things right first time

We move fast and accept the costs

We back our instincts on what is good

We rely on scrappy experiments to learn

 

The value of having principles with equally good opposites is that it gives you and your team a way of talking through the various options to identify the right approach.

Imagine for example that the Product Manager and the Designer on your team are working on a new feature, but disagreeing over the scope. Perhaps the PM wants to keep the first version of the feature more minimal and is willing to cut corners in the experience to get something delivered quickly, whereas the Designer wants to include additional animations that provide a more delightful and memorable experience that they believe will be more successful long term.

In the absence of guiding principles this disagreement comes down to which of the PM or Designer can better exert their opinion, and whatever the result it is likely that both of them will leave dissatisfied.

Rewind and imagine that their organisation had as a guiding principle: “we strive to give customer’s value sooner” (rather than its opposite: “we take our time to craft delightful experiences”). In this case it would have been easy to settle the disagreement, because the principle clearly dictates that the faster option is to be preferred.

Even better: if the guiding principle is widely communicated and well understood, the disagreement is unlikely to arise in the first place. The culture of the team and their approach to work will be in line with that principle from the start, and everyone will be working with the same state of mind.

Why not add an option for that?

Evan Martin:

If you've ever developed software you've surely had users ask you to add an option. "Rather than forcing everyone into behavior A," they'll reason, "why not add an option so users can choose between behaviors A and B?"

This post is an attempt at producing a canonical consolidated answer to why the answer to this is often "no".

Such a good and clear list of reasons why “just adding it as an option” is (probably), a bad idea.

In summary:

Options are features, and features are expensive

  • Adding an option introduces a bunch of questions
    • Where does the option live?
    • How does it get toggled?
    • How do we tell users about the option?

Implementing an option isn’t a one time thing - you have to keep maintaining it

  • As options are features, you have to maintain them like featyres
  • Every option you add can introduce multiplying effects on the difficulty of testing and debugging your product

3 questions everybody should know the answer to

Sanjay Poyzer:

Everybody on your team, every attendee of any meeting, should know the answer to these questions — or at least be trying to find the answers.

Those questions are:

  1. What is the problem we’re trying to solve?
  2. How do we know it’s a real problem?
  3. How will we know when we’ve fixed it?

From my experience, asking “What problem are we trying to solve?” is one of the most powerful tools for re-focusing a conversation.

The uncomfortable part is that, whilst often the PM or senior stakeholder will be able to answer the question, most others in the room or on the team will struggle. This isn’t their fault - of course - but that of the PM or stakeholder for jumping straight into discussing solutions without ever framing the problem.

Product managers == evil?

Patima Trantipraust:

There are probably two types of devs. Those who’ve worked with excellent Product Managers, and everyone else.

Trantipraust's post has been shared a lot today, and I think the conclusion is right: Product Management as a discipline is badly defined and frequently misunderstood. Many people see it as the glory role where they make the decisions and tell other people what to do, rather than being the invisible catalyst that brings out the best in the team.

In short, there are lots of bad product managers out there.

Product Discovery is a Team Sport →

Good tips on including the whole team in user research, by Austin Nichols:

All too often, Product Managers (and maybe a designer or two) go off on their own discovery conquest. After their long journey, they bring their divine user insights back to the team. Developers and QAs then get on with delivering the actual product. There is a common reluctance to involve the whole team. We can’t take technical folks away from their keyboards. What if we fall behind schedule? It’s their job to code! RIGHT?

No Machine Learning in your product? Start here

Nice post from Clemens Merwald introducing Machine Learning concepts to Product Managers, based on his experience at Google.

In the machine learning (ML) era, leveling up your Product Management team with some ML knowledge and skills is more vital than ever, and you might be surprised at how accessible the essentials are. And yet, those skills are all too rare. I’ve spent years in the trenches as a PM at Google and have distilled some of the learnings into a couple of blog posts for you.

Being a PM gives you a great vantage point from which to watch technology evolve. Personally witnessing Google gradually integrate ML in a majority of our product offering? What a view! I’m excited to share it with you…

This is part of a new blog series from Google called *The Leaver*. Sure to be one to follow.

My Product Management Playbook

I love learning about how to better build better products. These are some of my all time favourite blog posts on the subject:

(I’ll keep updating this list when I read something extra-special)

So you want to manage a product? by Rohini Vibha
This is the one I share when people ask: “What does a Product Manager do?”

Everyone is totally just winging it, all the time by Oliver Burkeman
Re-reading this always helps me bounce back from a bout of Imposter Syndrome.

Product strategy means saying no by Des Traynor
This is a great list, and knowing it well can help you catch yourself when your guard is down and you’re tempted to “just say yes” to some feature request.

Software Inventory by Joel Spolsky
An all time great blog post, on how to keep your backlog sane.

Eager Seller and Stony Buyers by John Gourville
Just because you’ve built a new product or feature and think it’s cool, why should anyone else care?

Product Land (Part 2) by Richard Pope
Techniques for thinking about problems in different ways. Reading this is like when Neo learns to see the Matrix.

What Google Learned From its Quest to Build the Perfect Team by Charles Duhigg
After thousands of hours of research, Google concluded that the secret to high performing teams is ‘psychological safety’. The best teams weren’t the ones with the smartest or most experienced people, but the ones where everyone on the team felt free to contribute without fear or rebuke, rejection, embarrassment. This is fundamental in how you as a PM get your team collaborating.

A Product Manager's Purpose

“So what do you do?”

“Uh - I work in technology, making apps and websites”

“Oh cool! So you’re a programmer?”

“No, not really, more like focusing on how the app should work”

“Ah ok, same as my friend then - she’s a designer”

“Well not really. I’m more responsible for choosing what the app should do, and managing the whole process of creating it”

“Got you, so kind of like a Project Manager”

“Um - yeah sure, kind of. Anyway, so what do you do?”

All product managers will have had a conversation like this at some point, where they fail to properly explain what it is they do. Surely, Product Management is the most misunderstood, misinterpreted, under-appreciated role in software product development, evidenced by the hundreds (thousands?) of blog posts and books that try to explain the role. The mistake is often that they focus on what the Product Manager does, when they should be focusing on what the Product Manager is for.

The reason that product management is so hard to explain is because the output is hard to define, or rather the role is not defined by its output. Developers write code, designers create wireframes and visuals, and copywriters write copy, but Product Managers aren’t defined by creating anything obvious and tangible. Or at least they shouldn’t be. I’ve seen many who think their job is to be spec-writers, Jira curators, slide deck creators. They have not been good PMs.

Good PMs should know their purpose very clearly: they are responsible for ensuring that the team is building the right thing, and that the thing is built right. This means that they decide what things could and should be built, and amongst those things which is the right one to build next. Then, they execute the plan to get the thing built to the right level of quality to achieve the thing’s aim.

The tools and techniques they use to fulfil this purpose are varied, and there are many excellent and helpful resources on the subject. But we shouldn’t worry that our role is hard to explain because we can’t point at a specific thing we’ve made.

Why functional specs are agile

When I moved to a new job and discovered they were using Google Docs to write functional specs I was…shocked. This was a nimble, fast-moving company that was winning awards for its apps. Surely they weren’t using word-processing tools to design their features? Big documents that list out the behaviour for a software feature seemed so un-agile.

I’m pleased to admit that I was wrong.

Writing functional specs for your project is a more agile way of designing software, and will result in a more focused team and better quality product.

More agile

Writing down exactly how your software should work forces you to confront potential complexities or inconsistencies in a much more agile fashion than many other practices, because it is so easy and cheap to adapt once you start getting feedback. They’re only words after all.

More focus

Writing down exactly why you’re building the software forces you to focus only on the features that are important to your goal, and gives the development team a ‘North Star’ to follow when making technical decisions.

Better quality

Writing down exactly what your software will do forces you to tackle the specifics that can otherwise so confidently hand-waved away. It is easy for everyone to agree “and then the user receives an email with a confirmation of their booking”, but it’s not until you have to write it down that you realise you also have to decide what the text of that email should actually be.

Specs at the right time

Of course as with all software projects, the key is getting the right level of detail at the right time. I am not advocating you open up Google Docs on Day 1 of a project and start writing detailed scenarios and edge cases and other kinds of product whataboutery. However on Day 1 you probably should write down the core goal of the project, and a summary of the background that’s led you to this point (e.g. why this goal is important). Then, as you move through your discovery and research, you begin fleshing out the spec with your learnings, slowly creating a skeleton for the project. Ultimately you will flesh it out with specific details, but not until development is just about to start - i.e. at the right time.

Product Whataboutery

In Product and Design circles, a lot is talked of ‘focusing on the problem’ but many people misunderstand the point of this mantra.

‘Focusing on the problem’ does not mean nitpicking problems in an idea. It does not mean obsessing over edge cases. It does not mean that - whilst discussing a suggestion - you spend your whole time saying ‘but what about…

What people miss in the ‘focus on the problem’ mantra is the focus. We want to ‘focus on the problem’ so that we can put the attention and energy of the team on solving a core problem. Shooting down observations, recommendations, and decisions with ‘whataboutery’ will lose that focus and distract the team from achieving its core goal.

Killing the Product Development Assembly Line

Nice post from Lisa Zhu:

One of the main causes for this team-wide dissatisfaction was our product development process, which at the time looked like this:

The Executive team made new feature requests; PMs helped prioritize these ideas and fleshed these out into requirements. We then sent requirements to the designers, who then cranked out designs. Exec-approved designs then went to the engineering team, who built the feature according to spec and tested it. Once everything was working correctly, we launched it to users. Rinse and repeat.

This approach (let’s call it the Product Development Assembly Line) created a few serious problems.

We all talk about working collaboratively and agile-y, but the process Zhu describes is far more common than we care to admit. The problems with the Assembly Line are mainly personal: the team has reduced visibility and control over decisions (becoming “pixel pushers and code monkeys”), and so lose motivation.

The new process Zhu suggests is not complicated or revolutionary. The challenge is persuading people that this (less obviously efficient) workflow will produce better results.

Set criteria before brainstorming

Brainstorming sessions have a bad reputation, but my experience is largely positive. They can be exciting and motivating, giving the participants a chance to have their voice heard and giving you a diverse pool of ideas.

The downside comes when brainstorming sessions go off track, either because people start discussing other things or, even worse, because people start discussing an idea that doesn’t solve the problem.

To resolve this, at the beginning of a brainstorming session I set criteria for what a good solution will look like. For example the criteria might be that the solution has to:

  • be reusable
  • be scalable
  • move key metric
  • not require a mobile app

Setting these criteria does not prevent ideas from being suggested, but it can help shut down a discussion that is not productive by getting people to evaluate the idea against the criteria.

Stop naming your projects after solutions

We, as Product Managers, are always told:

“Focus on problems, not solutions”

And we, as Product Managers, nod along and agree:

“Yes, yes, I always focus on the problem. I just wish everyone else in my organisation could stop talking about solutions”.

And then we, as Product Managers, go and call our next projects:

  • Message Archive
  • Reorganise Homepage
  • Payment History

Once you call a project by the name of the solution it becomes much harder to focus on why you’re implementing the solution in the first place. The objective of the project becomes do this thing, not solve this problem. You lose sight of the ‘real why’.

Human minds are lazy and will attach great importance to shorthand and proxies. It’s easier to think about the name of the project than it is to think about the purpose of the project itself.

This is dangerous if we name our project after the solution, but is something we can turn to our advantage by naming a project after the problem it’s trying to solve. This forces our lazy human minds to focus on the problem we're trying to solve, and can help us understand when we're ‘done’. We’re not ‘done’ when we’ve built a ‘Message Archive’; we’re ‘done’ when users no longer have messages in their inbox that they consider irrelevant.

Let’s try renaming our projects so that they reflect the problems they're supposed to solve:

  • Message Archive - Users don’t need all the messages in their inbox
  • Reorganise Homepage - Users can’t find the most important stuff on the homepage
  • Payment History - Users need to see how much money they’ve spent

Words matter. Name your project after its real why.

Media Diet: February 2018

End of the fucking world: Weird but fun, and not really like anything else. You can (and should) watch the whole thing in an afternoon. B+

True Story: I put this on on a rainy Sunday afternoon without knowing anything about it, and it ended up being a far more compelling story that I expected. Nice to see Jonah Hill be serious. B+

Good Time: Robert Pattison being super creepy in an 80s homage is definitely not light entertainment but still makes for an interesting film. B

The Departed: Not seen it for ages and remembered it being much better than it was. The story telling is confusing without being clever. C-

Captain America: I’m not a big superhero movie fan, but as far as they go, this was pretty fun. B

Captain America: The Winter Soldier: Also fun. (These are new on Netflix in Spain, hence the binge). B

Patriot: Starts out like it’s going to be a bog-standard HomeLand-a-like spy drama, and then completely subverts expectations. Weird and sad, violent without any glorifying. Definitely recommended. A