10 Rules for a Successful Product (or How To Work With Developers and Designers)

(calm retro music) - Thank you very much.

I'll have to apologise up front, I'm gonna be relying pretty heavily on my notes here. I'm not gonna be as charismatic and out and about as everybody else was this morning. My name's Patrick, I'm a product manager at Domain. Right now I'm the only thing that stands between everybody in this room and lunch, so without further ado I would like to dive into my two-hour presentation (audience laughing) on how to construct the perfect JIRA ticket. (audience applauding) Strap yourselves in.

Or not.

I grew up in Silicon Valley during the heart of the dot-com bubble, and while working there I learned the value of really understanding user needs and creating a product that really delivered value. Granted, this was working at a pizza place, so probably not the best way for me to establish credibility.

Now, I don't claim to have all the answers. In fact, on any given day I find myself asking more questions than giving answers.

But I have had the good fortune to work with a lot of fantastically smart and dedicated people in my career. So, over the next little while I'm gonna share some of what I've learned to help product managers work more effectively with design and engineering professionals to build successful products.

And this has all been conveniently distilled into 10 rules, because who doesn't love a clickbaity list. Rule number one.

Shared documents equals shared understanding. There's no better way to ensure that everyone is on the same page than by sharing that page with everyone.

There are heaps of products that make it easy to share documents with everyone in your company.

So, share documents often and liberally, your colleagues will thank you.

And don't bother adding notes when sharing. This will ensure that everybody opens the document and reads it in its entirety to see how it applies to them, if at all.

Number two, work in secret.

Nothing good has ever come from working in the open. This is how trade secrets and competitive advantages are squandered.

This is particularly applicable within your team. Make sure that your designers don't share prototypes with anybody but you, and that your developers keep their code closely guarded. None of this opensource nonsense.

Even internal code reviews pose a security risk. Number three, avoid conflict.

If there's a disagreement brewing within the product team, I've found the best course of action is to just ignore it. Encourage your team to bottle up their feelings. Most issues will resolve themselves without any direct involvement from you as the product manager.

If the issue's really important someone will bring it up to you in a one-on-one, which you should absolutely be having, once every 12 to 18 months or so.

Number four, assume what the user wants.

Now let's just be honest and get this out of the way, users aren't very smart.

If you had asked people in the 19th century what they wanted in terms of advancements in transportation, they probably would've asked for faster horses. Silly, right? The solution's simple.

Don't bother with user research, don't bother with empathy, don't bother to try to understand your users. You're just wasting precious time.

You are the product manager, all of you, and you know best. Just trust in yourself.

Number five. Accessibility can wait.

There's a saying going around that accessibility is like a blueberry muffin, and that you can't just jam the blueberries in at the end. Lies.

(audience laughing) I tried this last week.

The muffins turned out fine.

So, don't spend your scarce design and development time worrying about accessibility, okay? It's totally safe to assume that your users will have access to high speed internet, especially here in Australia where we have the NBN, (audience laughing) modern browsers, and have full use of a monitor, keyboard and mouse.

If you need to bolt on a couple features at the end, tick off your WCAG requirements, those can all be done just prior to release. (audience laughing) Number six. Dictate the how.

It's your product and your vision.

It's your job to tell the designers and developers how to do their jobs.

If left to their own devices, chances are they'll get creative and deviate from your carefully crafted user stories. You know the best place for that button to be. Who better to dictate how the API handles a particular request than you.

Now, it's okay for people to contribute their ideas, but at the end of any meeting it should be clear that you alone have the final say.

Number seven.

(audience laughing) Late changes build character.

When a feature comes to you for acceptance testing, this is a perfect opportunity for you to change your mind about fundamental parts of the design.

Developers in particular love the challenge of making sweeping changes with a rapidly approaching release deadline that you committed them to. Number eight. Good design is easy and don't let anyone tell you different.

Controversial? Perhaps.

I suggest there are plenty of books and online examples of how to design good products and services. So, you need to resist the temptation to engage in time-wasting activities with your designers, like story mapping, empathy building or prototyping. Instead, just point them to an example of how you want your product to look and ask them to copy it.

(audience laughing) I don't know why everyone's laughing.

This is really disheartening.

(audience laughing) Number nine. Work in silos.

Developers and designers are experts in your field. You hired them because they're smart people and they excel in their chosen discipline.

Why would you distract them by asking them to do absurd things like talk to each other? Keep distractions to a minimum by keeping designers and developers separate and let them do their job.

Lastly, number 10. Keep your distance.

Your time is far too valuable to spend it listening to everyone bicker and complain during retrospectives and complain endlessly about estimates and planning sessions.

You need to be there out in the field taking credit for everyone else's hard work. The team will appreciate the trust that you've placed in them to work based on your vaguely-written user stories. Or not.

In case it's not obvious at this point, which it sounds like it was, you should do absolutely none of those things if you wanna deliver a successful product.

In fact, you should do the complete opposite. Let's pick these apart a bit one by one.

Shared documents does not equal shared understanding. It takes actual conversations to make sure that everyone's on the same page, not just a collection of slide decks or dashboards. You need to genuinely listen and take other people's opinions into account. During those conversations as a product manager, you need to gently distinguish between facts and opinions and, most importantly, don't take things personally and don't judge.

As a product manager, you should have strong opinions that are weakly held.

Now, while I was working on this presentation, I spoke with one of my early coaches and mentors who summed up this mentality really well.

So I'll pop his quote up on the screen here. He said, "In the face of facts "that show my previous position was incorrect, "I change my mind. What do you do?" - I said wow, Kareem, that's really great. I love it. Did you come up with that? He said, "Hmm, maybe." And then seconds later, "Yeah, probably not," and then he sent through a link to the origins of the quote. But I really did enjoy his brief optimism at his own cleverness.

Work in the open, it makes things better, full stop. The sooner you share designs, prototypes, hypothesis, code, just about anything, the better.

While working on the Australian government design system, we made a decision early on to make everything in our product open.

Our roadmap, our code, our designs, our community, our decision-making process. And we were a really small team, and we were relying on the grassroots support of the community, both from the private and public sector, to help us get stuff done.

And to the best of my knowledge, this was something that hadn't really been done in the Australian government before, at least not to the extent that we did.

And I really believe that it was that decision and the dogged stubbornness to stick with it that led us to delivering such a great product. Healthy conflict is a good thing.

We've heard a little bit about conflict already this morning.

There's gonna inevitably be a time where there's some kind of disagreement in your team. That's natural, it's just life.

But you should encourage your team to sit down and talk it through.

A product manager should examine a discussion from all sides.

Try and take other people's positions and come up with what you think is the most convincing and best argument for that side, and then weigh them against each other.

Taking things personally during these discussions or avoiding disagreements altogether is really toxic. You need to keep in mind, we don't always hear exactly what the other person is saying.

We often hear our opinion of what we think they're saying. It's okay to disagree and still commit to a decision as a team.

The important part is that conversation.

Never assume what the user wants.

I would hope this one is pretty self-explanatory. The value of regular contextual user research has been proven again and again, and any product manager who assumes they know what their users want without having spoken to them regularly is a fool. Involve users early and often in your design and prototyping process.

Bring them in to walk through a story map when you're looking at what to build next.

I guarantee you'll spend less time reworking code and be delivering value sooner.

Think about accessibility from the beginning. Now, this is potentially more of a moral imperative than a rule, unless you're working in the Australian government and it is a rule. But I believe it's important none the less. This is I think the only time I throw statistics into the presentation, but over four million people in Australia have some form of disability.

So that's around one in four people.

Sorry, one in five. Awful math.

So whatever product you're building or whatever service you're delivering, chances are that some of your users are living with a disability. If the moral imperative argument isn't winning you over, a study by the Australian Human Rights Commission found that customers with a disability are three times as likely to avoid an organisation and twice as likely to dissuade others because of an organization's negative diversity reputation. So, long story short, don't bolt it on at the end. Think about it from the beginning.

Let your team come up with the how.

As a product manager I believe you should bring the what. Bring your team that future blog post announcement of your product's release, and let them start to break down the how.

Know where to draw the lines about what you're responsible for as a product manager, but don't be afraid to speak up.

For example, if you wanna suggest a technical approach to your developers, do it humbly, but don't be angry if it's discarded. Communicate with your team.

Learn how to communicate so your messages are heard by the recipient.

This means the message may have to be delivered differently to different people.

What this really boils down to is know your audience. You need to understand when a direct and blunt conversation is gonna be effective and when you should take a more tactful approach. Good design is hard.

Anyone who tells you different is probably lying or trying to sell you something or both.

Work closely with your designer or designers to build something, measure, learn and repeat, over and over.

Break down silos.

Encourage your team to work together.

Some of the most effective teams I've worked with had designers and developers sitting side-by-side, enthusiastically arguing with each other all day. They'd go back and forth sharing ideas, rationale, looking up documentation, pointing at the screen with furious intent, coding together and then eventually settling on a middle ground that they could both live with.

If all the designers sat together and all the engineers sat together and they just lobbed JIRA tickets back and forth at each other over the proverbial wall, I guarantee that the final product wouldn't have been nearly as thoughtful and considered. And lastly, be a part of the team.

For me, this is one of the hardest ones to internalise. It feels a little esoteric.

What does it mean to be a part of the team? Jeff Patton who wrote "User Story Mapping" and hosts great workshops on product leadership, talks about the concept of a trio of individuals leading the product team.

The product manager, the UX designer and a senior engineer. Within that trio, everyone should be aware of each other's strengths and each other's weaknesses, and they should take advantage of them.

The strengths not the weaknesses.

Great design and great products don't just happen, they happen when people collaborate to solve problems from different perspectives. So what does this mean for product managers and how should you be a part of the team? I've tried to boil this down into some model behaviours and habits, and no tricks this time.

There's not another secret list after this. Product managers should clearly define the what. This means thinking critically and sticking to the facts. You need to be intellectually honest with your team. You need to know where things are and don't distort the truth.

People can smell BS from a mile away.

Communicate what the product and the team and the organization's guiding principles are. For every piece of work, help everyone on the team understand what's important. The flip side of that is to make sure everyone understands what's not important.

David touched on this when he talked about managing priorities and scope this morning. You need to remove any ambiguity around the team's priorities.

Make an effort to understand the other roles in the team. You could ask your teammates for recommendations on books or podcasts that they go back to time and time again to better understand how they see their role. This will help build empathy.

And that word's come up a few times today.

What do I mean by empathy? Sharon Steed who's a principal at Comunilog, she talks about empathy a lot.

And I had the good fortune to hear her speak last year at another conference, and she recalled that she often hears empathy defined as, "That thing you have to do "in order to not be an asshole at work." I suppose that's not untrue.

But she also uses a more functional definition which is, empathy is the ability to understand and share the feelings of another.

And I think teams work when each team member feels listened to and genuinely understood. As a product manager, one of your roles is to facilitate this.

Genuine empathy is integral.

Be an umbrella.

Now again, earlier today David talked about how being a meeting and email shield isn't necessarily something that product managers should aspire to, and I agree. But context is important.

You need to make sure your developers and designers can do what they're paid to do.

This means going to meeting so they don't have to, assuming they aren't required to be there of course. Communicate at those meetings and competently represent your team and their disciplines as if they were there, and then take and circulate good notes.

Speaking of good notes, write stuff down.

Requirements, write 'em down.

Decisions made, write 'em down so you don't have to revisit them later.

To-dos, write 'em down and distribute 'em.

The big caveat here is just don't let that be the only way that you communicate with your team. Finally, let your designers and developers know that you expect them to challenge you, and that if they do it it won't be taken personally. Kind of hyped on about this a lot, but they own the how and they need to make sure their input's taken into consideration.

A healthy tension between design and development and product is a good thing.

So there you have it, 10 rules.

Well, 20 if you count all the fake rules at the beginning. And despite its questionable provenance, I'd like to leave you with that quote that my friend Kareem definitely didn't come up with, because I think it nicely sums up the ideal mindset of a product manager.

"In the face of facts that show "my previous position was incorrect, "I change my mind. What do you do?" Thank you.

(audience applauding) (calm retro music)