PRODDUCT London

I had a lot of fun hosting a PRODDUCT event at ustwo London this week. We had an amazing turn out and a great discussion on the future of Connected Car technologies. Excited for the next London event. Stay tuned!

The importance of size & proximity

Process is expensive. Bigger teams, working from a distance, part time team members, and many specialists are all factors that lead to a more elaborate process. This might be obvious, but the more companies we get to know, the more we experience that this is something being ignored. Here’s a 3 minute video that dives into the importance of team size and proximity: 

PRODDUCT at Spotify

I had a blast last night hosting a PRODDUCT event at Spotify! We had a great turn out and I personally got a value out of the discussions and the ideas that the audience presented. We kicked off the event with a quick product design activity where I asked audience members to sketch out a new feature for Spotify’s iOS/ Android app. Audience members were given five minutes sketch out their ideas and then present them to the audience. It was great to see the amount of audience participation there was for this activity. We then had a fireside chat with Jason Yip, who is an agile coach at Spotify. We dived deep into Spotify’s Product Development process and left plenty of time for audience Q&A. Below are some of the pictures from the event:

Sprint: Solve Big Problems and Test New Ideas

I’m a huge fan of the Lean UX methodology when it comes to solving problems and building better products. Another book that takes the whole Lean UX methodology to the next level is Sprint by Google Ventures. The book offers the same themed day approach where a five-day process leads to answering crucial questions through prototyping and testing ideas with customers. A typical week using the Sprint approach looks like the following:

Source: Sprint Book
Source: Sprint Book

 

The following playlist goes over each day of a Sprint week and what makes the process special:

 

Lean UX: Writing Hypothesis Statements

In Lean UX, the starting point is having a clearly written hypothesis statement. This gives your entire team a clear focus for their work. It keeps everyone aligned and sets the right constraints. In order to arrive to a well written hypothesis statement here are some of the steps:

  1. Declare Assumptions – A high-level declaration of what is believed to be true.
  2. Hypothesis – Specific descriptions of assumptions that target your product
  3. Outcomes – Metrics that can help validate your hypothesis. These can be both qualitative and quantitative
  4. Personas – Users for whom we are trying to solve the problem
  5. Features – The product changes or improvements that may solve our problem

First, based on specific user and business assumptions you want to write a problem statement using the follow template:

[Our service/product] was designed to achieve [these goals]. We have observed that the product/service isn’t meeting [these goals], which is causing [this adverse effect] to our business. How might we improve [service/product] so that our customers are more successful based [these measurable criteria]

Next, you want to come up with some user assumptions by asking the following questions along with your team:

  1. Who is the user?
  2. Where does our product fit in hi work or life?
  3. What problems does our product solve?
  4. When and how is our product used?
  5. What features are important?
  6. How should our product look and behave?

After stating the assumption for both your users and prioritizing them based on level of risk. The final step is to write a hypothesis statement using the following format:

We believe [this statement is true].

We will know we’re [right/wrong] when we see the following feedback from the market:

[qualitative feedback] and/or [quantitative feedback] and/or [key performance indicator change].

Most of the time the main hypothesis can be hard to test when building out specific features. To break the hypothesis down further, you can create sub-hypothesis to test specific features using the following format:

We believe that 

[doing this/building this feature/ creating this experience]

for [these people/ personas]

will achieve [this outcome].

We will know this is true when we see

[this market feedback, quantitative measures, or qualitative insights].

Once your hypothesis statements are written. The next step includes deciding on the Key Performance Indicators that can validate your hypothesis for each feature build. This should again be done collaboratively. I’ll talk more about how to determine the right KPI to measure success in the next post. Stay tuned!

Getting Out of the Deliverables Business

How do you practice Lean UX when you have teams in different time zones and different locations? Implementing a Lean UX product management practice definitely works better when your team is in the same office but it shouldn’t be an excuse if your have teams in different cities across the world. Jeff Gothelf, the author of Lean UX, shows how teams in different office locations can still take advantage of the Lean UX process. Moreover, he shows why product management teams need to get out the deliverables business and start creating shared understanding within their teams:

 

10x not 10% Product Management

It’s often easier to make something 10x better than it is to make it 10% better. – Astro Teller, Google [x]

10x Not 10% : Product management by orders of magnitude by Ken Norton at Mind the Product 2015 from MindTheProduct on Vimeo.

Ken Norton in this talk emphasizes the importance of having a 10x mindset when solving product problems and how it should be a way of thinking.

05JaIVidwblbsvv6O
Photo Credit: Ken Norton

He gives the example above where most companies make decisions based on the option that has the highest probability of success rather than the option that has lowest probability of success but the highest outcome without looking at the expected values of each option.

It shouldn’t matter if you work for a large company or a small startup. The following are some principles you can apply in order to start thinking in a 10x way:

Failure must be an option 

Great work comes overtime by repition and learning by failure. In product management, the more you ship the better the quality of the products you ship become. “Pefection is the enemy of progress” quote applies here.

People want to do great work, let them

Majority of the time people perform their best when they get to work on problems that interest them. Google is famous for giving their employees 20% time, other innovative companies have hack days every quarter. Moreover, transparency is a key component to this so that every team member knows what everyone else is working on. Default to open policy allows better collaboration and creates the environment for people to their best work.

Use data, not opinions

By backing your decisions with data, teams move faster becuase less time is spent arguing and more time testing assumptions to see what works and what doesn’t.

Measure impact, not effort

As product managers it’s easy to get caught up in the nitty gritty details of launching a feature like managing bugs in a que or number of engineers involved. Instead to obtain the 10x mindset it’s important to measure the impact. “We will have accomplished this” not “we need to do that”

Be bothered by limitations

Limitations will always be there in every project. To really make that leap from 10% improvement to 10x results you can’t surrender to limiatations but instead be bothered by them.

Bet on trends

Timing definitely plays a huge role in launching successful products. Achieving that 10x result can be a lot about launching something at the right time. Slack and Periscope are two companies I think have taken advantage of that. Instant messaging within work was  available through products like Basecamp’s Campfire product but the adoption wasn’t there when 37Signals originally launched Campfire. Same with Periscope, Livestream had a similar product way before periscope but cell phone devices didn’t have the resolution or speed when they originally launched.

To learn more about these principles I recommend reading Ken Norton’s original post on medium that talks more about this. These principles definitely have allowed me to shift my product management approach and the way I solve problems. How will you shift your thinking from 10% to 10x?