Mind the Product San Francisco: Live Blog

Welcome to Mind the Product San Francisco! We are live from the SFJAZZ Center, with 600 product managers, nine speakers and an awesome day ahead.

Keep refreshing your page to keep up-to-date on all the action and follow #mtpcon on all the usual social media channels. If you’re at the event then keep Tweeting these great posts and photos, enter our competition, and have a great conference!

—–

Kathy Sierra
Building badass users

On one side we have Typical UX and on the other we have Tranformative UX — what if we could bring those together?

We can think about typical UX, and also transformative UX in terms of the Ordinary world, and the extraordinary world. Everything we do makes a difference: we can bring some of the extraordinary world into the user’s life.

Every experience has the potential to be transformative.

Thought experiment: add “world” to whatever users do with your product.

Reduce cognitive leaks – not so much “don’t make me think” but “don’t make me think about the wrong things”.

Should products feel alive?

Humans anthropomorphize everything! My cat is trying… to kill me? Try some experiments with Google autocomplete on “my computer is trying…”.

Research has shown that conversational language causes people to pay more attention. This research gave us Clippy! Manuals are not written for real people and we can never make the perfect product, so we can Just Tell Them. Tell them: “the manual sucks, we know”. Acknowledge your customers – the Kindle Fire has a Mayday button.

Amazon announced “75% of Fire HDX customer contacts come via Mayday”

To craft an extraordinary world:

1. Help them feel more human
2. Help them find Flow through challenge

Flow: The Psychology of Optimal Experience –  Mihaly Csikszentmihalyi

Flow state: total focus, no worries, in the zone.

“If your product needs a manual there’s something wrong with your product” – this is nonsense! That’s like saying if your brain surgeon was good enough he wouldn’t have had to read any books.

There’s a distinction between tool and context.

What you make is the tool and what they’re using it for is the context. The tool UI should be easy so the context can be hard. The Flow lives in the context, not in the tool.

Think of your product as an extraordinary experience and imagine the person is always asking “What can i do in this extraordinary world?”

Use: tip of the day, user examples (not testimonials) and focus on what’s possible (and what’s possible in the context). Make a reminder for users!

The Hero’s Journey – help users step from the ordinary world into the special world.

—-

 

Jon Kolko
Founder and Director of Austin Center for Design
@jkolko
Product process:

Establish vision
Drive consensus
Ship product

Two qualities make up a product: Product/Market Fit and Behavioral Insights. Think about Google Glass – we’re not ready for wearing technology on our faces, but we are used to wearing glasses on our face. You need to make sure users get the value back that they expect. Behavioral insight is also based on identity, and an aspirational version of identity!

What makes a great product manager? 

To be a great product manager you need:

1. An ability to tell stories about an optimistic future
2. An ability to make sense of signals from people and the market
3. A passion for listening to people (be interested not interesting)
4. Curiosity about other disciplines
5. Be affable

So what does a product manager do?

Contextual research
Synthesis and sensemaking
Behavioral insights

Value proposition
Feature definition

Launch & usage metrics
Iteration and extensions

Communication strategy
Community feedback

That sounds great, how do I get into product?

Get your hands as dirty as possible.
You have to have some experience building something. Go make something.
Ship something.

—-

TOM CHI
former Experience Lead, Google X
@thegoodtomchi

Rapid prototyping & product management

A lot of the lessons learned in rapid prototyping are directly applicable to product management.

Key lessons:

1. Create a culture of learning
2. Stay in the medium
3. Optimise loop length

Create a culture of learning

A culture of right and wrong. Even if you fail, if you learned a lot of things then, in a culture of learning, that would be highly praised. A culture of right and wrong is intrinsically diminishing – a highly additive culture.

Essential: Track and Measure Key Learnings

A key learning is an embodied or observed experience that materially changes your path forward. Key learnings can only come from an observed, embodied experience.

Google Glass projected keyboard:

If you think about it, when you have lazers coming out of your head, then you look at your friends, you’re going to shoot lazers into their eyes.

Don’t rely on debating right and wrong, move into using key learnings to make a path forward.

Avoid Guess-a-thons

Guesses aka “conjectures” are opinions about what will work without yet having an actual experience.

Guess-a-thon meetings are pointless, and are essentially asking: “What is the truth of the invention that has not been invented yet? The next time you’re in a meeting ask yourself whether you’re using embodied, observed experiences to make decisions or is it becoming a Guess-a-thon.

The mantra: Creating a Culture of Learning
Conjectures become experiments.
Actuals become decisions.

Lesson 2: Staying in the Medium

Consider: What is your medium?

Product Builder Medium: human behavior in the Real World.
If you’re far away from that then you’re completely out of the medium.

Product Management Medium: Uncertainty.
Product managers have an interesting medium – through the process of wrangling uncertainty something beautiful comes out.

Lesson 3: Optimize Loop Length

Loop length = amount of time between asserting a new conjecture and observing its actuals.

If you’re continually integrating every day, but not learning anything from actuals from customers, that loop is open and it needs to be closed.

In practice: Creating a Cadence

Customer feedback chunks in your cycle need to be non-negotiable.

When you’re 95% committed the world is really hard, if you’re 100% committed the world is really easy.

In practice: Mall Prototyping

The mall has a store to cater to your specific audience. If you approach with an away team of 2 guys you have a 40% chance of success, if you’re a guy and a girl you have 55%, and 2 girls has a 70% success rate.

Find “Eyes Light Up” moments aka “Magic Moments”.

This is what you’re product is all about. Your product is this magic moment, and your task then is to add features that add to and amplify this magic moment.

Innovation grows from insight/adaptability

Adaptability becomes answers: start out any new process with a design for adaptability

Scalability becomes answers

– separating these two allows you to get further with these types of processes.

Uber has TWO magic moments: button = car, and leave without paying. THAT’S why they’re worth $50b. The magic moment at Uber is not what the login flow was like!

Your product is not the world, your product gets used in the world.

—

Rochelle King
Global VP of Design and User Experience, Spotify
@rochelleking

 

 

Conflict

Agitating the creative process with conflict can lead to some really rich discussions. Embracing conflict can be liberating at times.

Five things I’ve learned about dealing with conflict along the way:

1. Worthy: Conflict is exhausting. you don’t want an engagement unless it’s for something worthwhile. There are few times in the product development cycle that are devoid of conflict, so it’s important you’re aligned in what you’re doing and that you believe it’s worthwhile.

Make sure the temple is worth getting to, that it’s worthwhile to cross the river, and that it’s worth going to battle for.

One of the best ways to align your teams is by having clearly identified success metrics.

Make sure metrics are very closely aligned with what users are doing. Success at Spotify is measured by engagement, but also by music – and whether people are actually listening to it.

So before you know if the goal is worth fighting for you need to make sure you can express your side. Create a culture of engaging in debate. You can ask people to debate against the things they believe, and this creates a safe environment in which to have these arguments – it’s a staged situation.

Ask your enemy to debate things with you, and then you’ll get useful feedback in a safe environment. It also helps you build a better relationship with your enemy. Then you can open your product up to people and let the data help you decide.

Remember that behind every single point of data is a person, and data allows you to have a conversation with that person.

Conversation allows you users to articulate back to you what they want and what they like. Inject difference and conflict in to these situations to learn.

Look for patterns in the conflict – once you find them you can take a step back and see the larger picture.

Engage in conflict, not to focus on winning, but to focus on what you can learn. Even though you might not enjoy conflict it will push you in the creative process and allow you to build great products.

—-

RYAN SINGER
Product Manager, Basecamp
@rjs

Tools and context

Password protected blog for clients, lots of little blogs for clients’ projects and this became Basecamp.

One of the best tools is a map – a map of all the capabilities that need to be present. Basically the map is, when I close my eyes, how I see the product.

Nerd definition: Orthogonal capabilities = two things that can move independently of one another (as opposed to coupled).

Focus on things that are part of the domain. You often see people mapping things out but they are implementation things, so we need to focus on the capabilities. This allows you to get to a wonderful state: done!

Orthogonal is the road to sanity – it allows you to mark off all the things, as they get done.

 

A simple brain dump is useful, but you’ll need to bring some domain expertise in. A domain expert knows about the real life situation that your product is for, and knows what the system needs to do.

You can then start to group your list items, and now you’ve gone from a large unmanageable list to a smaller one, with an understanding of the boundaries you’re going to work inside, and this allows you to create the map.

 

 

Two things keep your map grounded in reality: time and affordances. Affordances is a word you’ll know from UI: think about the teapot – the capability is the pouring of water, the affordance is the handle.

—-

Linda Rising
Author, Lecturer & Consultant
@RisingLinda
Science versus Stories

A short survey:

How many are doing <the latest and greatest>?

How did your organisation decide to do that?

How many looked at the randomized, controlled studies that provided evidence that <the latest and greatest> is better than your current process?

We rely on good stories

Our short history is not about progress based on scientific experiments; instead we jump on the latest bandwagon because we hear a good story. These are not even really case studies.

Why test “common sense”?

How many believe that <the latest and greatest> practices don’t need formally evaluation because they’re so obviously common sense?

Medicine – a science?

Bloodletting?
Leeches?

It was common sense best practice for 2,000 years! Medicine is not a science. Physics is a science.

Data and evidence are sometimes ignored.

What if drug companies operated the way we do?

– Drugs would be offered on the street corner! They work for me, so you should try them!
– Even drug companies late in recognizing that controlled experiments were not enough.

Randomized, placebo-controlled, double-blind

Real treatment and control not sufficient
Placebo arm is required
Not instituted until 1950s

Check out Linda’s talk: Is Agile a placebo?

Why do placebos work?

Organisations don’t encourage the scientific method

We don’t have the resources for one experiment, let alone the repeated experiments that good science requires

Decision makers want action not investigation

Many decision-makers resistant to the idea of “experiment” – the notion implies the possibility of “failure”

Even when experiments are carried it out it really just means “try” – no science 🙁 !

What CAN we do?

1. Test what we can

Check out Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience by Arlo Belshee.

2. Look at outside research

Behavioral economics has changed everything! Read Thinking Fast and Slow or anything by Dan Ariely.

3. Do food – together! 

This is difficult because a lot of product people are introverts, but you won’t learn anything eating lunch reading email, or on Twitter.

4. Diversity

Having women on teams makes those teams better!
What you really need to be able to sell your idea is a powerful story.

—-

Josh Brewer
graphic interaction UX product designer
@jbrewer

 

 

We become what we behold.
We shape our tools and thereafter our tools shape us.
Marshall McLuhan

We shape our products and thereafter our products shape us.
Josh Brewer

Looking down at our phones/devices is like wearing a 60lb weight around our necks. We don’t know what these devices, these products are doing to us.

Read: You Should be Afraid by Dave Pell.

The Apple Watch. What it came down to, is that this is the answer to the overwhelming distraction of the iPhone. The iPhone had a profound effect on our human behavior: it some ways it bought us closer. We are habitually trained to respond to every nudge and ding on our phone.

The phone is ruining your life… …was the reason they decided to make the watch.

As product people we are responsible for the ramifications of the decisions that we make.

We can’t just blame the medium itself.

Mind the Product. This conference started in the UK. Mind the gap. Mind the problem, be aware of everything you do.

What we make completely testifies to who we are. Jony Ive

Some companies are solving legitimate healthy problems

Behaviours that drive your engagement numbers potentially have a disastrous effect on us as human beings – not making the world a a better place!

Tech is the new rock n’roll. That’s the route that you take as a youth.

Companies are so hyper-focused on growth – we have to hit the numbers so we make the money.

The life of a designer is a life of fighting against the ugliness
Massimo Vignelli

This is not an argument for beauty and aesthetics. It’s about ugliness of process. There’s too much excess, not enough care.

We should have a desire that the things we’re putting into people’s lives are things that have care, that have consideration, even if we don’t understand the effect of it. Think about ‘why am I doing what I do? Why do I feel compelled to build products, to create?’

We are called to be the architects of the future not its victims.
R. Buckminster Fuller

—
Mina Radhakrishnan RADH
EIR, Redpoint Ventures & Advisor, Cowboy Ventures
@minarad

The Art of Saying No

 

1. Why do we say no?
2. Finding common ground
3. Seeking alternative solutions

Why do we say no? Try counting the number of times you say no in a day – and why. They’re usually transactional and not that hard, and we’re ok with walking away from that person and not worrying about it. But when you care about people it’s harder to say no as at some point in the future you’ll need something from them.

It’s relevant for product managers as we work with lots of different groups.

Prioritization is the main reason we say no. But prioritization is necessary and good.

• if resources were infinite we could do it all
• articulating priorities forces us to prove value
• ask ourselves the tough questions so we have answers for others
• many ways to prioritize

If you chase two rabbits you will lose them both.
Russian proverb

Avoid prioritizing by effort alone!

We’re all guilty of it but there’s lots of ways to prioritize. Saying no based on effort alone will make you look bad! But effort is still an important factor.

To define priorities we need:

• Goals
• Success metrics
• Timeframes
• Potential solutions

Find agreement on company goals

As a PM we need to have respect for every single person we work with, it doesn’t matter what level they are or what our relationship is with them. Fundamentally, it doesn’t matter who we are – we’re here to make the company better.

Listen. Listen. Listen.

Be quiet, listen, and take in what people are saying.

It’s never a waste of time.

Explaining people and projects

1. Discuss what the solution would involve
2. Focus on value and relate back to goals
3. Show resource allocation

Can you find the intersection of goals?

Without finding the common ground the conversation doesn’t go anywhere.

Understand the problem

Don’t assume you know what people are doing – they won’t come to you with problems, they’ll come to you with solutions.

What can we do?

For features:

• Feature in an upcoming version – be honest, and if things change let people know so you’re standing behind your promise
• Use a combination of existing tools
• Automated email reports – find a good analytics package

For product we can:

• Reduce scope
• Research and circle back
• Escalate

Building a product isn’t necessarily the answer.

—

Marty Cagan
Managing Partner, SVPG
@cagan

Product Fail 
The Root Causes of Failure
For every Uber, for every Airbnb, there’s a thousand failed companies. Google Glass – even within a great company there’s failure.

We can’t innovate anymore – I hear that all the time – and it takes forever to get an idea live.

Everything starts with ideas. There’s two main sources of ideas:

• Executives/business owners
• Customers

Most companies’ goal is to make a roadmap. In order to make the roadmap they will need to do some kind of business case. Companies want roadmaps to know you’re working on the highest value things first, and so there’s some level of predictability in the business. In order to know what to put on roadmap and what priority, they do a business case. Might include how much value it will create, how much it will cost, and level of effort.

This is what the process looks like at most companies:

Hopefully you will recognize this as Waterfall. This is how teams have worked for a long time.

It’s incredibly ineffective and why so many teams fail.

Why is it so bad?

1. The source of the ideas. The best source of ideas is your engineers! They’re working with the technology every day and in the best position to see what’s now possible. Another favourite source of ideas, for me, is data. It’s typically not in the hands of the people doing the ideation.

2. Business Case Fallacy

In tech products the most important thing to know is that you can’t know. You can’t know how much money you’re going to make because you don’t have a solution yet, you just have an idea!

3. Product roadmaps.

These come from reasonable requests. But one of the two inconvenient truths about product: at least half the items on your roadmap are never going to work with customers. I can’t tell you which ones – we don’t know until we go through the normal way of working.

The  second inconvenient truth is that the ones that are going to work are going to take several iterations before they work well enough to make money.

You might not run out of money, but you might run out of management patience. What matters is not time to market, it’s time to money. Time until it’s valued, or is value.

Be stubborn on your vision but flexible on your details.
Jeff Bezos

We have alternative to roadmaps.

4. The Role of Product

The role has changed dramatically, and is in the process of changing. You guys are ahead of your organizations. The role is often described as needing the product manager to “gather requirements”. A lot of the role can actually be project management – if it wasn’t a product company that is what the role would be called. Gathering requirements is not the role of product.

5. The Role of Design

It’s not a very fun job being a designer in this model. It’s tough – you’re essentially starting to work on something where a lot of bad decisions have been made.

We need teams of missionaries not teams of mercenaries.
John Doerr

This process is a mercenary one. Way too many product managers create wireframes and hand them to designers. If you’re spending your time doing wireframes you might be a gifted unicorn interaction designer, but probably not! You’re probably no better at interaction design than any of your engineers would be, and if we looked at your product we’d probably be able to tell.

You might as well spend the money and work with a visual design agency.

6. The Role of Engineering

If you’re just using your developers to code, you’re only getting about half their value. This doesn’t mean all your engineers want to spend all their time with customers, but we need some of them at least to engage heavily. Developers are often coming in way too late, don’t understand the context and we aren’t getting the benefit of their knowledge of what’s possible.

7. The Role of Agile

The process is not “agile” as it’s not flexible on details. [Thanks and shout-out to @producttape who filled us in on this one, live blogging is hard!]

8. Output not Outcome

We don’t get points for output, we get points for outcome. The problem with this process is it’s all about getting things done.

9. Customer Validation Too Late

Feedback from customers happens at the very end.

10. Opportunity Cost

This speaks to what you could have been doing instead of messing around with Waterfall.

The best teams don’t work in this way.

Continuous discovery and delivery

OKR’s = an alternative to roadmaps.

Ideas: vision and OKR’s

Discovery: MVP tests

Delivery: Product/Market Fit

Is it:

• Valuable
• Useable
• Feasible
• Ethical – should we build it?