If you’re not learning anything, you’re wasting your time


We must visualise product learning work in the same way we visualise delivery tasks, and this must be taken seriously by the team.

In my previous post I made the case about how we’re losing control over the ‘learn’ part of Build — measure — learn and how important it is for us to do more learning and less building.

To counter this, our team at YLD had been trying to solve how we can visualise learning work within our process. Doing this successfully would mean we never lose sight of what we are/aren’t learning and the whole team can view the progress of this pursuit of experience.

I’d like to share where we are with our solution at the moment with the intention of sparking a broader conversation, so please reach out and share your thoughts!

In pursuit of delivering a great user experience

True Story №1: Quality is a huge differentiator when it comes to delivering products with a great experience.

“Just because something works, doesn’t mean its good” — Anthony Mann

True Story №2: Our product process has to be a balance between the quality of our product, and the time it takes for us to build it.

“Don’t waste time building something that doesn’t work”- Anthony Mann

These may seem like very obvious statements but they are surprisingly overlooked. We can easily fall victim to our own processes handed down to us by the Lean and Agile gods as we react to time pressures– as opposed to taking control of them.

Our way of avoiding this from happening, we believe, would be solved by visualising learning work.

How can we visualise learning work?

First, we need to measure the product progress in units that really matter.

Within our teams we’d have discussions around how confident we were in the designs we were creating.

  • How confident are we that our solution is creating the success we want for the product?
  • What do we need to do to build confidence in this solution?
  • Based on what we’ve measured and learned, how confident are we in this build?

Having to consciously make a decision and really think about how confident we are that a particular area of the product is meeting our expectations meant that we are critically analysing the product at every level.

We started speaking in Confidence. 🗣

In order to make those decisions, the desired outcome we were looking for needed to be crystal clear. If they weren’t clear this would immediately render that area low in confidence until our assumptions were tested.

The more we did this, it became a habit to think in this way.

We started thinking in Confidence.🙇🏻‍♀️

We could speak to each other about how an area of the product we just tested was in low confidence as 8/10 users failed to understand it. We could speak about a new feature being in high confidence as 10/10 users were delighted when interacting with it. We were able to speak about an area being in medium confidence, if users successfully completed the task but the experience was mediocre and there was still significant room for improvement.

We started measuring in Confidence.📏

Frequently asked questions 🙋🏻

How do you know something is in low confidence?

A lack of certainty and the presence of doubt before testing an idea indicates low confidence .

Users unsuccessfully completing a task indicates low confidence.

Failing to understand technological limitations would indicate low confidence.

High drop-off rates in your analytics indicate low confidence.

Or vice versa: a high drop off rate could substantiate the assumption that the concept has no value to the user — boom, high confidence.

Stakeholder requirements taking priority over user experience indicates low confidence.

The list goes on…

How do you know something is in medium confidence?

Users successfully completing a task but the experience is sub-par indicates medium confidence.

A very slight increase of certainty that your product is delivering value to your users indicates medium confidence.

A critical area of your value proposition resulting in average feedback would indicate medium confidence

How do you know something is in high confidence?

A delightful on-boarding experience that funnels your first-time users through a flow would indicate high confidence for that part of the product.

Setting high expectations (KPIs) and then surpassing them would indicate high confidence.

Significant increase of user engagement would indicate high confidence.

Why do you need a medium confidence?

This comes back to our overall goal of delivering a compelling user experience. Defining what ‘high confidence’ looks like at the outset means we can measure the distance from where we are to that higher level. Between sprints, you may show signs of minimal improvement but the desired outcome has still not been achieved.

Having a middle ground allows contingency for progress.

In terms of making a judgement call on whether something is medium will really come down to how critical that particular area of the product is to your users. If it’s a significant part of your value proposition, being mediocre is unacceptable.

If a significant chunk of your product, in the previous sprint, was in ‘low confidence’ and in the current sprint it scored ‘medium’ then you’re making great progress!

What benefits does this bring?

  • Doing this pushes the products beyond ‘good enough’.
  • Doing this avoids us becoming enslaved by delivery-focused practices.
  • Doing this ensures you never lose sight of the WHY.
  • Doing this reveals areas in your product that need urgent attention.
  • Doing this educates the team on why it is necessary to change your plans.
  • Doing this ensures the team is collaborating with a greater goal of creating compelling experiences.
  • Doing this motivates the team to continuously improve.
  • Doing this emphasises the severity of poor decision making.
  • Doing this emphasises how well you are doing.

Speaking, thinking and measuring in confidence eventually led to us visualising in confidence.

I’ll be sharing a series of shorter follow-up posts that show how we’ve visualised confidence in our product development and delivery tools so you can get an even better idea.

As always, I’d love to hear your thoughts so please do reach out.

Ciao!


Written by Hana LodhiNovember 4th, 2017


Share this article