I speak later today at Mind The Product, an event about product management and design, in London. Here are my notes from the sessions so far.

1. Martin Erikson

Product management is about people. You can only build products people love as a team. Product managers are not the CEO of anything. Regardless of your job title, we are all product people. Perhaps instead of calling ourselves product people, we should call ourselves people people. We can only learn how to do this well by coming together and sharing what works and what doesn’t. Which is why he founded Product tank – the core community behind this conference. 1592 product people from 52 countries are here today. The goal for today is to meet the people who mind the product.

2. Jake Knapp , author of Sprint

(hi-five training – the secret is to watch the elbow, not the hand)

2001 – Jake worked on Encarta (Remember CD-ROMs?). Soon wikipedia launched, which they found interesting but didn’t take as a threat. But by 2003 it had more artiles than Encarta did, and using the web for research, which was always there and always free, even if the quality wasn’t great.

Jake proposed an idea – it took months to prototype, build and ship. And they did. It was a more web-like design for Encarta. But unlike today, you had to go to physical stores to buy software (no-app store). The box design was important – and the logical thing would be to show the new design and the name of the product – but they didn’t. They made the mistake of waiting till the end to involve the marketing team, which went with a generic design. The major redesign work earned a single bulleted list buried on the front. Soon Encarta’s market share declined until the product was killed (if you do a google search for Encarta, the first result is from Wikipedia).

He went to Google in 2006 and recognized they often followed the same broken process. And sometimes with 20% projects the idea would spin out of control and never quite launch. Later on a project called “Google Meeting” and they built a prototype and stating sharing it around the company. In 2011 it launched as google hangouts.

In 2010 he experimented with the idea of design sprints. In 2012 he went to join Google Ventures, which worked with startups. He was curious about how startups managed the ideas and time and discovered it was similar to the same old failed process, with marketing coming in late at the end, too late.

Build-Data-Idea cycle – classic notion of not going too far without validating and adjusting.

The perfect week (the design sprint): get rid of all default habits of scheduling, and follow a system (aim for the elbow). By default, teams are fragmented. But in a sprint everyone is all together in the same room for the entire week.

Monday: Map – focus on one key moment for the customer. You draw a map of the flow of interaction for how the customer will walk through the experience.

Tuesday: Sketch – everyone sketches – you work alone, but together in the same room. Everyone quietly sketches solutions and then gather together to discuss them.

Wednesday: Decide – silent review of sketches, structured discussion of each idea, and the “decider” makes the call

Thursday: Prototype – the work gets divided up and simple tools get used to mock things up and stich them together. With hotspots it’s not hard to create something you could even show to a customer and walkthrough the experience.

Friday: Test – get quick and dirty data with 1:1 interview, with no sales pitch and asking them to think aloud. 5 interviews and the rest of the team takes notes. Observations are put on wall with post-it notes to compare observations.

Next sprint: Repeat and perfect

Some organizations plan to run a sprint at the start of each quarter, and then have enough confidence to push through to building a shipping. Jake has run 150+ design sprints.

He told a story of designing a delivery robot for hotels. One problem was that people had way too high expectations (from movies) of what robots could do. Using a design sprint, they experimented with three ideas: games, faces and dancing. The game idea didn’t work, but a simple face design combined with “dance” (more of a shimmy) was just charming enough without setting people’s expectations too high.

Design sprints allow you to take big risks, and focus on the moments of the experience that matter the most, without costing very much (one week).

3. Blade Kotelly  (Advanced Research Lab, Sonos)

Edison didn’t invent the light bulb. It was Joseph Swan. But Edison successfully made it into a product and changed the world.

He asked the audience questions: Is innovation important? (many hands) Is user experience important? (many hands) Does user experience as a competency have a strategic role at your company? (few hands). He implied this was a mistmatch of ambition and reality.

A problem well stated is a problem half-solved. – Charles Kettering

He uses a ten step process in the design thinking course he teaches.

1. Identify
2. Gather Information
3. Stakeholder Analysi
4. Operational Research
5. Research
6. Hazard Analysis
7. Specification
8. Creative design
9. Conceptual design
10. Verification

Two phases of innovation:

• Phase 1: Learning how to think about solving the problem, defining questions to use to help define the problem. “Is this really a problem? Who’s problem is it? What words best describe the problem?” (He calls this experience center-lining)
• Phase 2: Standard design process

Apple Newton had the wrong centerline. Processor wasn’t fast enough, it was expensive and too big. The Palm Pilot had the right centerline.

4. Teresa Torres

She worked on a project for college alumni, and by accident they were allowing spam to go out to the mailing lists they had created. They brainstormed and one idea that teammate Seth suggested was to add google maps so alumni could see where they all are. She asked “how does this solve the problem?” – and he said it didn’t, but it was cool and would drive engagement. She asked the rest of the team and they agreed. Teresa was baffled.

We fall in love with our ideas, even if they don’t apply to the situation at hand. We have to remember to ask “is this idea any good”. We tend to consider one idea at a time, when we should be asking “compare and contrast” questions. Good is not an absolute trait, but we often assume that it is. When we consider more ideas we ask better questions.

She realized she didn’t take the time to get the team focused on the real problem at hand. The notion of problem space and solution space have (gratefully) become more popular.

She found value in the book Peak, by Anders Erickson. Which explained that experts have more sophisticated mental representations of reality than novices. Teresa came to the meeting from customer visits and was thinking about their problems. But Seth had just read about Google Maps APIs, so his framework was different.

It’s hard to prioritize a list of unlike items. You need a system or process to ensure you are thinking clearly about the comparisons you make. She described the Opportunity Solution Model, a tree like visual tool for framing problems to aid in critical thinking. If you focus on too many problems you end up with shallow solutions.

Instead of arguing about who’s idea is better, you instead argue about which problem is more important to solve.

She explained how dot voting is a handy technique to use with teams to sort through candidate ideas.