Pairing for Product Managers

An interesting post from Anne Thomas on what it’s like to do ‘pair product management’:

I recently had the chance to pair with another Pivotal product manager on a more extensive basis. I also got a chance to speak with other PMs at Pivotal about their experiences “pair PMing”. As it turns out, a lot of the benefits we see from pair programming also apply to pair PMing.

I often spend time thinking over a problem or coming up with a new development idea, but as soon as someone else looks at it they spot things I hadn’t thought of. Sometimes even just the act of speaking my own thoughts aloud to someone else makes me realise there are pieces missing. Pairing with another person on this thought process can help avoid these situations.

The problem with pairing is obvious: it’s expensive. It is hard to justify having 2x the people working on 1x the projects. The counter argument is that you will get much higher quality output, but admitting that quality would be significantly higher if you paired can feel like admitting that you’re not good enough on your own.

An extremely helpful and relatively lightweight scenario to pair as a PM is when it comes to prioritising - either features ready to build or problems you haven’t started tackling yet. Having to justify to someone out loud why one thing is more important than another can remove hidden (or even acknowledged) biases, like prioritising a bug because you were the one that reported it, or picking a project because you know it will be fun.

In ‘Turn the Ship Around!’, one of David Marquet’s key discoveries was that his submarine crew made significantly higher quality decisions when they had to speak their actions aloud before proceeding, because it forced them to be conscious and deliberate in their choices. Product development is only marginally less complex and dangerous than nuclear submarine operation, so it's probably worth product managers trying this too.

Tiny wins

Great post by Joel Califa:

Over the years, I’ve worked on many important, large-scale projects, from figuring out high level strategy and blue sky products, to overhauling core flows and IA, to implementing design systems from the ground up.
Working on these big projects can be exhilarating. They’re often deemed critical by company leadership and various stakeholders, and it’s validating to be trusted with and attached to something so visible and impactful.
I recently shipped two things at GitHub that had an impact beyond my wildest dreams. The amount of gratitude and love that spilled out of the community is like nothing I’ve seen before. But the things I shipped weren’t these huge, meaty projects. They were tiny.

When you think of the services you love the most, they’re filled with the small things that delight you. If there are enough of those in a service it can make you forgive the other absences.

The difficult thing is getting air cover for this - prioritising this over other features is hard to justify. The whole point of these features is that they’re things your users would never have requested, so you can’t reply on customer feedback, and I can’t see how you could have any supporting numerical data either. How do you get your team to buy into something that is just ‘gut feel’?

Even if you manage to do that, how do you get these tiny wins past your senior stakeholders that are expecting a new feature that will get that big customer to sign, or that will increase your market share and help meet your investors’ targets?

Feature inventory

“Feature backlogs. Every product attracts new feature ideas, and you can’t implement ideas as fast as you can think them up, so you write them down, and this list is called the feature backlog. A lot of the ideas on the backlog are bad ideas, and you merely wrote them down to avoid hurting the feelings of the people who thought them up. Backlogs make everyone feel good.

The trouble is that 90% of the things in the feature backlog will never get implemented, ever. So every minute you spent writing down, designing, thinking about, or discussing features that are never going to get implemented is just time wasted. When I hear about product teams that regularly have “backlog grooming” sessions, in which they carefully waste a tiny amount of time and mental energy every day or every week thinking about every single feature which will never be implemented, I want to poke my eyes out.

Suggestion: Do not allow more than a month or two of work to get into the feature backlog list. Once the backlog is full, do not allow new items to be added unless you remove an item. Do not spend any time speccing, designing, or talking about backlog items: the backlog, in fact, should be seen as a list of things you are not allowed to talk about or work on.”

This was written in 2012 and is still so good. Worth coming back to every few months to force some self-examination.

Media diet: January 2018

Jason Kottke does a monthly roundup of his 'media diet'. His definition of 'media' is extremely broad, so far having included: music, film, TV, books, exhibitions, holidays, and more. I always enjoy skimming through his lists, so this year I'm going to try the same. He gives each item a high school-style grade and I will too, but as he says: "don't take them too seriously".

La Belle Sauvage; by Phillip Pullman: I loved the original His Dark Materials, and re-read them over the summer (they're still great) in preparation for this, but La Belle Sauvage was....only ok. It felt much more like a childrens' book than the original trilogy, and there was too much magic for my taste. (C+)

Lincoln in the Bardo; by George Saunders: The Booker Prize winner, and on everyone's 'best of 2017' lists. The writing style is so weird - some chapters are dialogues of reported speech between ghosts, others are made up of citations from both genuine and fictional sources - that I found this very difficult to get into. I'm pleased I persisted though, because this turned out to be a moving and unusual novel, unlike anything I've ever read. (B)

McMafia: The BBC tried to recreate the success of The Night Manager by copying the formula almost exactly: young British actor flying around the world to exotic locations to meet dangerous and wealthy people, occasionally having to commit crimes but all in the name of doing 'good'. Unfortunately for them, it missed the mark massively. Utterly vacuous, completely dull. Couldn't get past the 3rd episode. (F)

Molly's Game: A fast-paced film featuring a compellingly written and acted woman navigating the world of high-stakes poker, based on a true story. Not groundbreaking or thought provoking, but very good fun. (B+)

Peaky Blinders, S4: I don't think I like this as much as everyone else seems to. I enjoy the depiction of an unusual period/location, but the story and acting is completely overwrought and ruins it for me. Adrian Brodie is the guy at the fancy dress party that keeps doing his (bad) Marlon Brando Godfather impression. Not sure I could watch the next season. (C)

The Crown, S2: This was fantastic, as good again as the first season. I never would have thought that I'd like this as much as I do, but the writing, the acting, the set design, and everything else is so well done. And it's tense! After every episode I was looking up the stories on Wikipedia and wasnconstantly amazed that these things actually happened. (A)

Sing, Unburied, Sing; by Jesmyn Ward: Another one from the 'best of 2017' lists. Slightly odd, very enjoyable. (B)

The Post: Another true story with a well written, well-acted female lead. I didn't know much about these events, and ending on the very beginning of the Watergate scandal was a nice touch, but it wasn't exactly gripping. Good, but not great. (B)

 

 

Be Deliberate

Steven Sinofsky published a fantastic tweetstorm this morning. Nominally it was about Twitter's new - um - tweetstorm thread feature, but really it's about a classic product development problem: how to add more functionality without adding disproportionate complexity.

This is an extremely familiar feeling. So often what we're working on is a mature product that is meeting its core goal, or as Sinofsky (and every other Silicon Valley VC) puts it: you've got Product-Market fit.

When you're trying to get Product-Market fit, you're constantly iterating on your product, adding new features, adapting the design, changing your marketing strategy. It's a desperate race to find your market before your product or project dies or is cancelled.

And that's the thing with Product-Market fit: you often don't know you've found it until much later. This makes is extremely difficult to know when you can (and should) stop iterating, adding, adapting, changing. Even if you do know you've found it, the instinct to keep moving gets into your bones and can be hard to shake.

What all of this often means is that Product Managers in charge of mature products can often find themselves doing everything right, and yet still doing everything wrong. They are out listening to customers, designing well researched features that move the metrics in the right direction and that their customers like. It feels good.

The cumulative effect of all of these new well researched and designed features - added after you've found Product-Market fit - is that it will make your product ultimately too complicated. There is no disputing this: you can't keep adding new features without experiencing some trade-off in complexity.

So once you realise you're in this position, what can you do? I honestly don't know. The most obvious answer might be to start removing the 'bloat' features, but by that point it is likely too late: You will be told "oh no you can't remove that! Customers X, Y, & Z signed long contracts off the back of that functionality."

So maybe once you're into feature bloat, you can't reverse it. But how do you avoid it in the first place? One option might be to just do nothing, but this is extremely difficult and in any case not realistic. As Sinofsky says, when you stop moving you become a static target for your competitors.

Instead you need to be deliberate. Keep moving, but deliberately. Don't stop adding the new, but add less of it. Be sure about what you're adding.

Be deliberate.

Remove the legend to become one →

Extraordinary post from Eugene Wei. Ostensibly it's about how to make better graphs, but it's surely the most compelling, beautifully written post about Excel charts ever written.

“Even with that process, much could go wrong. While I tried to create guardrails to preserve formulas linking all the workbooks, everything from locked cells to bold and colorful formatting to indicate editable cells, no spreadsheet survives engagement with a casual user. Someone might insert a column here or a row there, or delete a formula by mistake. One month, a user might rename a sheet, or decide to add a summary column by quarter where none had existed before. Suddenly a slew of #ERROR’s show up in cells all over the place, or if you’re unlucky, the figures remain, but they’re wrong and you don’t realize it.

Thus some part of every month was going through each spreadsheet and fixing all the links and pointers, reconnecting charts that were searching for a table that was no longer there, or more insidiously, that were pointing to the wrong area of the right table.

Even after all that was done, though, sometimes the cells would not calculate correctly. This should have been deterministic. That’s the whole idea of a spreadsheet, that the only error should be user error. A cell in my master workbook would point at a cell in another workbook. They should match in value. Yet, when I opened both workbooks up, one would display 1,345 while the other would display 1,298. The button to force a recalculation of every cell was F9. I’d press it repeatedly. Sometimes that would do it. Sometimes it wouldn’t. Sometimes I’d try Ctrl - Alt - Shift - F9. Sometimes I’d pray.

One of the only times I cried at work was late one night, a short time after my mom had passed away from cancer, my left leg in a cast from an ACL/MCL rupture, when I could not understand why my workbooks weren’t checking out, and I lost the will, for a moment, to wrestle it and the universe into submission. This wasn’t a circular reference, which I knew could be fixed once I pursued it to the ends of the earth, or at least the bounds of the workbook. No, this inherent fragility in linked workbooks in Excel 97 was a random flaw in a godless program, and I felt I was likely the person in the entire universe most fated to suffer its arbitrary punishment.

I wanted to leave the office, but I was too tired to go far on my crutches. No one was around the that section of the office at at that hour. I turned off the computer, turned out the lights, put my head down on my desk for a while until the moment passed. Then I booted the PC back up, opened the two workbooks, and looked at the two cells in question. They still differed. I pressed F9. They matched. ”

Sorry about the huge quote but it's seriously all so good.

The actual point of the post - how to make graphs better - is pretty much summed up by the title. The quickest, easiest way to make your line graphs easier to read is to delete the legend. Instead, label the data series directly on the chart. Easy, huh?

Running in Circles

Fun post from Ryan Singer:

“Agile became synonymous with speed. Everybody wants more, faster. And one thing most teams aren’t doing fast enough is shipping. So cycles became “sprints” and the metric of success, “velocity.”
But speed isn’t the problem. And cycles alone don’t help you ship. The problems are doing the wrong things, building to specs, and getting distracted.
Claiming there’s a True Agile™ somewhere in the past or future doesn’t help either. When your team struggles with shipping, you need practical steps you can apply here and now. Not just an ideal.
Cycles are good. We work in cycles at Basecamp. But in addition to cycles you need three other practices to ship on time and in good health.”

I agree with a lot of this. So much of the conversation around agile is about efficiency and speed and being lean. Those things are fine, but the biggest problems in product development are more about misunderstanding the problem, jumping to a solution, or keeping people creative and motivated.

Singer's three principles:

Deliberate resource allocation

  • Allocating people to a project means dedicating people to a project. One of the hardest things in product development is keeping focused. Only management can protect their teams' attention.

Mutable requirements

  • One of the most obvious causes of a demotivated team is a lack of autonomy. Giving teams a list of requirements will kill all energy and worse: likely lead to building something that doesn't meet the need.

Uphill strategies

  • Product development is not a linear process - it's not moving a pile of stones from A to B, where you know how many stones you have to start with - it is about problem solving.
  • Singer's analogy is that problem solving is like traveling over a hill. There is a phase at the beginning where you don't know what you're doing. It's hard, but finally you reach through the clouds to the top of the hill and realise you can see the path all the way down the other side.
  • This means that there is significant cost in the early stages of a project where you don't know what you're doing. It's important to acknowledge that and giving teams time to reach the top of the hill.

The Cost Center Trap →

“Software development projects are normally capitalized until they are “done” – that is they reach “final operating capability” and are turned over to production and maintenance.[1] But when an organization adopts continuous delivery practices, the concept of final operating capability – not to mention maintenance – disappears. This creates a big dilemma because it’s no longer clear when, or even if, software development should be capitalized. Moving expenditures from capitalized to expensed not only changes whose budget the money comes from, it can have tax consequences as well. And what happens when all that capitalized software (which, by the way, is an asset) vanishes? Just as in the days when JIT was young, continuous delivery has introduced a paradigm shift that messes up the balance sheet.”

Time to Rethink Agile in Enterprise Startups

Interesting interview in First Round Review with Ogi Kavazovic from Flatiron Health:

“In Kavazovic’s experience, the two pitfalls described above boil down to a key misunderstanding: agile development and longer-term planning are NOT actually the mutually exclusive modus operandi the tech world has portrayed them to be.”

I think saying that the 'tech world' has claimed that long-term planning does not fit with agile development is a bit of a straw man. It's true that you should not make detailed plans many months or years into the future: they'll invariably be wrong and you'll have to change course. But what Kavazovic really means by "longer-term planning" is that you need to have a vision of the future that you're trying to get to, and it seems to me that that is wholly within the scope of agile development. The long term vision is especially important in Enterprise companies because, as Kavazovic succinctly states:

“There’s still a vital difference between consumer and enterprise sales: Selling to users vs. selling to buyers”

This is the classic problem faced by all software companies trying to sell to business. To persuade the software buyer to sign a multi-year contract, you need excite them with future developments that will justify their long-term contract. However in order to delight the software user, you need to iterate quickly through solutions to find what will meet their needs. Giving the buyer what they need requires certainty. Giving the end-user what they need requires experimentation, i.e. an absence of certainty.

“Agile is really good for making sure that you create a successful user experience. But it’s important to separate that from the overall product roadmap, which requires meeting the needs of your buyer.” The key is to take a two-pronged approach: 1) articulate a long-term product vision, but 2) establish a culture of flexibility when it comes to the details.”

Kavazovic's proposed solution to this tension is not so radical - it's essentially a rehash of the 'roadmap based on problems' framework - but it does present a neat way to meet the contradictory needs of the buyer and end-user.

Alpha to Live is not a linear progression →

“Organisations should start many discoveries. Discoveries should lead to sometimes one, sometimes many and sometimes no alpha projects being started. Some of those alpha projects might lead to a beta service being produced and live services should come from the successful beta services.”
Michael brunton-Spall, https://medium.com/@bruntonspall/alpha-to-live-is-not-a-linear-progression-f38e49f5a52f

Michael brunton-Spall, https://medium.com/@bruntonspall/alpha-to-live-is-not-a-linear-progression-f38e49f5a52f

To be a better leader, Ben Horowitz thinks like Chance The Rapper →

“In some ways this may seem obvious, but very few managers are able to be themselves in business. For example, an excellent co-worker (we’ll call him Stan) gets his first promotion to manager, and everyone is excited. But once Stan becomes a manager, he stops being Stan and becomes “Manager Stan”—and magically transforms into a dick. He feels like he has to establish his authority, so he stops treating you like a person and starts treating you like someone he has to impress with his power. Nobody likes or follows “Manager Stan.””

Stupid title, but quite insightful. I think we have all seen people change like this and, even worse, perhaps have done it ourselves?

Dash-bored →

Ryan Dunn, on why 'dashboards' don't really cut it anymore:

“This is the important part for me. This subtle — but significant, and I think positive— shift from quite passive at a glance monitoring to much more active finding stuff out. Quite different things with the same name.

However a move from being told a story to being allowed to form your own — from explanatory to exploratory — presents a fundamental change in the expectations on our users —did anybody tell them?

This might seem minor. It probably is to the dashboard creators who feel they are offering the users the power to become more proactive than reactive. But this additional responsibility on users — the consumers — to have a conversation with the data, isn’t minor— especially in terms of data literacy and confidence.”

In short, the data needs of people in modern organisations are more sophisticated than look-at-a-standard-chart-on-a-dashboard, but that doesn't mean that the people themselves are data-savvy enough to be able to use tools available.

Research, don't test

We have a problem at work. A few years ago, everyone in the team spent several hours each week talking with our users. This might have been at our offices or, if we were lucky, it was out at theirs. This 'talking with users' wasn't completely aimless, but it wasn't strictly structured either. We wanted to find out about their work and about their life. About their typical day.

This open-ended, conversational research gets called many things. At GDS it's 'Discovery'. Where I work, it's called 'Customer Discovery. Whatever it's called, it's about identifying opportunities, finding unmet needs among potential customers. As Cindy Alvarez says in Lean Customer Discovery: "find out what customers need and what they're willing to pay for". What are the pressures, challenges, and emotions that customers have in their day. What are their 'Jobs to be Done'?

The problem we have at work is that we're not doing this so much anymore.

That's not to say that we're not talking to users, though: We're a good product team that reads the right blogs and the right books and thoroughly believes in a user-centred product development process. We have a research lab in the building and talk with our users all the time. The problem is in what we talk about.

Instead of talking about their problems and challenges and emotions, we talk about a thing we're showing them. We test ideas we have by building light-weight prototypes and putting them in front of users.

Prototype-and-test

Leisa's absolutely essential newsletter this week had links to two articles that discuss exactly this, and I suggest reading them both:

Alan Cooper calls the put a prototype in front of a user kind of research that we've been doing: 'Prototype-and-test'. Simon Roberts sums it up:

“Research has become less about questioning underlying assumptions and engaging with the complexity of culture and more about testing and validating objects and artifacts.”

I've not worked in the industry long enough to declare the 'UX-ification of research' a trend, but I find it reassuring that Cooper and Roberts have experienced the same thing. We also all agree on the reason for the diminishing importance given to Discovery-style research. It's: the fashion for Lean Startup and build-measure-learn loops; the attractiveness of 'Delivery is the Strategy' and 'Show the thing'; the pressure of agile iteration.

Open-ended research is necessarily slower than agile teams are used to working. It's not going to result in user stories ready for the next sprint, or at least not new code.

That's not to say that the prototype iteration is not important - I think it is, because we do need to iterate on what we've built - but it can't exist on its own, or be the only kind of user interaction the team has. We need to give some effort to looking ahead just a bit, to see what might be coming next or to reject potential ideas, and continue with renewed confidence that we're already working on the 'right' thing.

We need to occasionally come up for air, to check we're still swimming in the right direction.

8 reasons our service probably sucks →

A familiar list, from Matt Edgar:

“1 - We have understood some of our users at the expense of the others.
2 - We have understood our users, but not what they’re trying to accomplish.
3 - We have understood our users and tasks, but not their contexts of use.
4 - We have involved our users, but only every now and then.
5 - We have learned many things, but done too little with the insights.
6 - We have come up with solutions, but not enough to find a good one.
7 - We have optimised one part of the experience, while ignoring the others.
8 - We have some, but not all, of the skills to finish the job.”

The Poetry of Blade Runner 2049 →

Priscilla Page at Birth, Death, Movies has written the best article I've read about Blade Runner 2049.

“Like John Shade discovering that his near-death vision was not shared, K realizes that his memory of a wooden horse didn’t belong to him after all. It means he is not Rachael’s child, that he’s not a miracle, not special after all, but it no longer matters. The moment K thinks he is more and wants to be more, he becomes more. His perception is reality. It reprograms him.”

Like the very best books, I'm finding myself still thinking about this film well over a week since I saw it.

Storing and sharing user research

“We know it’s not helpful if user researchers have to start from the beginning each time - it can lead to people doing the same research repeatedly.

It’s wasteful, but it can also damage the reputation of user research in the department. If stakeholders are presented with the same findings from several researchers, it’s hard for them to see the value of user research as a method.

At first we tried to fix this problem with technology and got very bogged down trying to make tools work in the way we needed. With a limited budget to build anything ourselves, and with huge challenges due to multiple tooling and collaborative spaces across the department, we didn’t get very far.”

One of my favourite of the Government's 'Design Principles' is:

“Make things open: it makes things better”

Arnold's post is a brilliant example of this. Trying to store user research outputs in a way that extracts the maximum value from the research for other (potentially future) teams is incredibly difficult. In my current company we have been struggling with this for years, and got bogged down in attempts to build complex tools and storage structures.

Hearing that other teams in other organisations have been having the same struggles has given my team confidence that we should pursue a different route. The Home Office being open about their problems is making things better for us.

The False Clarity of User Journeys

“Humans like to think that they got to Here and Now through a clear journey of decisions made correctly. Alternative choices and missteps are lost to the unconscious.
Asking people about their journeys and even observing their journeys can get stuck in the idea that the unitary path is obvious and unique.”

This is a good example of the constant tension between the feelings of 'we need more information before we start' and 'let's just start and we'll learn as we go'.

Sommerville's point is good, but we need to remember: the fact that the User Journey is not the single obvious path does not mean that we need to create more Journeys to try and create a complete picture.

It means we need to bear in mind that our information is imperfect.