UX Cambridge: Jeff Gothelf, Better product definition with Lean UX and Design Thinking

Jeff Gothelf is an interaction designer working for Neo in New York. He blogs at his personal site and tweets as @jboogie. His book Lean UX is out next March from O’Reilly.

  • Going to discuss defining better products using techniques of Lean UX and design thinking; how to use the ideas and philosophies behind these methodologies for better product definition and to build better products.
  • Case Study: Plancast (a social event sharing site) — had a big launch, write-up on TechCrunch, VC interest. They spent five months building the service, but it didn’t live up to hype and they sold after 3 years. The founder wrote a post mortem on TechCrunch: initial feedback made them think there was lots of interest; they measured ‘vanity metrics’ (registrations/visits) which gave them a false sense of success; the business plan was based on intuition, with no proof that the market was there. “Most social networks feed primarily on vanity… Sharing plans doesn’t present the same opportunity to show off and incur the same subsequent happy feelings.”
  • Key questions they should have asked: How long do we wait before we launch? (They took 5 months — was this too long?); How do we define the right requirements for our product? What signals are we looking for from the market? (AKA: How do we define success?)
  • All questions that can be answered with Lean UX and Design Thinking.
  • Requirements are really assumptions — guesses at what will meet the market’s need, unproven and untested).
  • If you define your product by ‘looking into a crystal ball’, you’re doing it wrong.
  • If you can build a culture that accepts that requirements are assumptions, you can build a culture of experimentation, where failure is embraced.
  • If requirements are really assumptions, we change our language: “We know” becomes “We believe”; “Let’s build it” becomes “Let’s test it.”
  • Design Thinking can help! “The ability to combine empathy for the context of a problem, creativity in the generation of insights and solutions, and rationality to analyse and fit solutions to the context.” Applies to the entire team.
  • Lean UX: “The practice of bringing the true nature of a product to light faster, in a collaborative, cross-functional way with less emphasis on deliverables and greater focus on a shared understanding of the actual experience being designed.”
  • Fundamental principle: Prioritise learning over growth. Find the right answer first, then scale it out.
  • Early product definition assumptions include: Who is our customer? What pain points do they have that our products/services solve? How will our product/service solve their pain points? What features are important? What is our differentiation (how are we going to win/make money)?
  • …which we then turn into hypotheses: “We believe that [building this feature] [for these people] will achieve [this outcome].” (Measurable business metric.)
  • “We will know we are successful when we see [this signal from the market].” == Test Driven Product Development.
  • Turn these hypotheses into experiments.
  • Case Study: TheLadders. The CEO had a ‘shower epiphany’ and decided every user would have a ‘personal job search assistant’ at the company. Lot of work — website, call centre, phone systems — months of work, based on his intuition that it would work. Nine months in, customer satisfaction/retention/sales not affected. Had a requirement; should have been a hypothesis, which becomes a starting point from which we begin. Gives us success criteria and suggests tests we can run to figure out if it might work.
  • How to test ideas: “Landing page to nowhere” to capture intent. Could have run a manual process on a small number of people. Could have focused on what outcome we were targeting.
  • Always ask yourself: What problem are we trying to solve? How will we solve it? How do we know it will work?
  • How does this change the way a team approaches a project? Measure of progress changes from output to outcome. You can launch features and they can still suck. Focus on driving team towards outcomes — which scale up towards impact (e.g. revenue).
  • Many companies currently manage to output, need to focus on outcome and not task teams with responsibility for impact.
  • Case Study: TheLadders. We were tasked with improving email response rate. Cross-functional team, small sprints, iterating, testing, qualitative and quantitative data. Pushed response rate from 14% to 68%.
  • For every hypothesis, as you collect data you end up with three options: Kill it; pivot; or double-down.
  • Case Study: Lenddo (micro-lending with the concept of a social-network based credit score). Users weren’t returning to add people to their network. We did usability testing with Balsamiq prototypes. Got feedback from the field before we committed resources, mitigating risk by not building things that people don’t want.
  • Case Study: Sesame Street. Wanted to enter the tablet education market; a new market, heavy investment, high risk, long term initiative. We treated the entire case as an assumption: wanted to make sure they were putting their money into the right project in the right way. Did class observation, watched teachers and students interact all day; wanted to see if teachers had time to look at a tablet; did the kids know what to do with these tools? Is there a viable market? Version 1: PDF content test on a tablet. Interviewed teachers before and after and observed. Learned a lot about content, how device works within context of classroom. V2: Card-sorting with features/content with teachers. V3: Clickable prototype to validate workflow.  Not a single line of code written.
  • Case Study: <redacted>. Subscription service to high-end customers that function in groups. Growth had flatlined, so they wanted to pivot the product to appeal to a broader audience, including more individuals. Risks: Significant investment, cannibalisation of current members, no guarantee new audience was interested. How will we know we’re on the right path? Made a clickable mockup on iPad, went to a convention and observed users. Only 5 days worth of effort.
  • Case Study: Agile UX NYC 2012. There are a lot of up-front costs when running a conference. We didn’t know if we should do this; would anyone attend? We did increasing levels of fidelity of testing; first we put up a launch page to capture email signups; next we put up an EventBrite page to sell tickets (no speakers, no venue). Tickets started to sell; proved the market was there and worth investing in.
  • Lean UX and Design Thinking are not just for designers. Cross-functional teams bring perspective to the product definition process from all disciplines; bring increased empathy for the user; a greater level of ownership in what you’re building; everyone understands the ‘why’ behind every initiative; you learn more, and move faster, by sharing the discovery and creation process.
  • Case Study: PayPal. Very silo’d organisation, difficult to have conversations across disciplines, and a very serial, waterfall process. Now they are literally breaking down the walls between teams, starting to work in cross-functional teams, learning how to work together and deliver products faster. Seeing benefits of working closely with developers, PMs, designers, and other departments. Working faster, focusing on outcomes instead of a set of features.
  • Defining the right product reduces the time spent building the wrong product; builds team-wide momentum and shared understanding in a recursive loop (it is more exciting to work on something for two weeks then launch it than work on it for 18 months); and ensures resources are spent on the right initiatives.
  • In summary: Requirements are assumptions; focus on outcomes; work together in cross-functional teams to come up with ideas; test those ideas ruthlessly.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>