Small Team Lean UX Advice From The userexperiencedesign.slack.com Community

Gold Thread

Andy Parker{:target="_blank"} introduced me to the userexperiencedesign.slack.com community late last year and to start with I dipped into the channels every now and then. More recently though, I’ve found it a much more reliable place to get direct answers to questions I have about certain topics, resources and processes. Certainly much more reliable and supportive than other social networks.

The Lean UX approach had been suggested to me earlier last week and keen to get a better understanding I visited the dedicated channel. Waiting for me was a perfectly timed discussion thread. Not only explaining the process but framing it from a very similar viewpoint as I have in my current position. Rather than let the very pertinent advice get lost in the Slack archive, I decided to put it somewhere I could refer back to it.

The following content was copied from the userexperiencedesign.slack.com{:target="_blank"} ‘topic_lean’ channel. All contributors to the discussion have given their permission for the content to be re-published here.

Sonja Bobrowska: @sbobrowska{:target="_blank"}

I came to this thread out of desperation. And the first thing I see is @lauraklein’s post which describes my situation to the dot: "the most critical part of this whole thing might be getting individuals to start identifying assumptions that are baked into a lot of the roadmaps and features for their products. I’ve noticed in large orgs that somehow features just sort of appear out of nowhere. Or they come out of weird compromises in meetings. If product managers can start figuring out what the actual point of the features is and then figuring out whether there are things they could to validate (or invalidate) the direction, that would be helpful.”

I’ve just started at a 5 year old “startup” as a single UX designer with a CPO/CTO (so without a proper head of product) who developed the product with no user research and no testing since the company's beginnings. No user research. Ever.

I’ve now interviewed internal stakeholders (not a big company) and have a ton of material from which I want extract all the assumptions. And there’s going to be a ton of assumptions. I’m trying to wrap my head around on how to proceed with creating testable hypotheses out of those assumptions and then actually running all the experiments and tests to validate them, and my head is bursting because it’s such a mountain of legacy product stuff.

TL;DR: I need to talk to someone who knows what lean UX is and how to help people like me who are stuck with a ton of legacy product assumptions… Any good souls?

Also, this is my first UX design role =]

Louis Elfman: @lelfman{:target="_blank"} Louis’ website{:target="_blank"}

Well, Laura literally wrote a book called “Lean UX for Startups”, so you might want to pick her brain. Slash buy her book and read it?

Also, personally, I tend to identify assumptions along with PMs since I’m more user focused and not business focused. Is there someone on the business side (preferably who has read Lean Startup) you can partner with?

Also, perhaps prioritize them by importance and value?

Do a 2x2 (a 4-quadrant grid). Put each assumption on a post-it. Top is “low risk”, bottom is “high risk”, left is “low value” right is “high value”. Grab a couple trusted partners and prioritize all according to the axes. It’ll help bring some clarity to it

And remember, @sonja, that you don’t have to solve all the things. You can only fix so much, you’ll kill yourself if you expect yourself to do it all. First find out what the most valuable things you can do for your users and your org. Then tackle those and hopefully the rest will fall in line.

Dave Malouf: @daveixd{:target="_blank"} Dave’s website{:target="_blank"}

Another book and this one will give you things to do. How to make sense of any mess by Abbie Covert. it has direct frames for you to start applying … Last book again will help you help yourself “First 90 Days"

Would be great to get a general mentor for sure. Often local groups in different cities offer mentorship programs. Have you looked into that?

Adrian Howard: @adrianh{:target="_blank"} Adrian’s website{:target="_blank"}

In an attempt to be more directive with practices

1. You might find David Bland’s Assumption Mapping useful (video https://precoil.wistia.com/medias/03gut5mrca{:target="_blank"}, have to give email to watch I’m afraid) which is an evolved version of his Experiment Mapping stuff https://vimeo.com/70514942{:target="_blank"}. I've found it a really useful way to start digging into different assumptions & talking about the cost and value of different kinds of experiment. Especially to folk new to the idea. I think this will help you with your "how to proceed with creating testable hypotheses" problem.

2. You're in a five year old company. So I'm guessing that you've got a lot of feature lists that are getting built. Doing 5-whys on why each feature is being built https://en.wikipedia.org/wiki/5_Whys{:target="_blank"} can help discover what the org perceives the current customer problems/needs to be. You can then start to reframe than in terms of assumptions, and start looking towards ways to validate them.

3. Impact Mapping https://www.impactmapping.org/{:target="_blank"} is a kind of structured mind mapping technique that you can use to explore different options. This can be another way of teasing out what the organisation sees as the reasons for building features.

4. Since it's a 5 year old company I'm hoping that you've already got something close to product/market fit. Which means that, sometimes, raising the idea of assumptions being "wrong" can be… tricky. Something I've sometimes seen folk find useful is to start talking about assumptions in terms of OKRs https://en.wikipedia.org/wiki/OKR{:target="_blank"}. OKRs tend to be a bit longer term too, which may make sense if the product is more on track. I hate to add another book to the list, but Christina Wodtke's http://www.amazon.co.uk/Radical-Focus-Achieving-Important-Objectives-ebook/dp/B01BFKJA0Y{:target="_blank"} is both good and short.

On the community/people front you may want to reach out to the Balanced Team folk http://balancedteam.org/{:target="_blank"}. It's a community that grew out of UX and Agile folk talking, its where I first heard of the stuff Janice Fraser et al were doing with Lean UX way back in 2010, and has a bunch of folk who have been playing with these ideas for a while. There's Yet Another Slack, DM me an email if you want an invite. Also an email list, link of the website ;-)

On the book front I'd ​personally put Lean Startup at the bottom of the reading pile since it's not that useful for practices. It is, however, a much better book at convincing business/management layers about the value of the more experimental approaches. So it might be a book you want to get your boss or grandboss to read.

I would second @daveixd's recommendation of Making Sense Of Any Mess. The content is good but, possibly more importantly, it is a ​masterclass​ in explaining concepts to folk who don't grok the concepts. Looking at the way Abby explains IA to an audience who don't know anything about IA may have some useful lessons for you.

Laura's UX for Lean Startups, if you've not read it yet, is more practice-oriented than Lean UX — so that will be worth a look. However it is more focused and startup-startups, so may be less directly relevant to your current context. However it is both refreshingly blunt – and written to non UX folk — so is possibly a better book for the rest of the team to read.

Dave Malouf: @daveixd{:target="_blank"} Dave’s website{:target="_blank"}

Another piece of advice, is start every meeting about a next release kickoff with the questions: What do we need to learn next and what is the least we can do in order to learn it and do we have to put it into production to learn it? (create a culture of learning and the rest falls into place)

Apply it. go through your application alone (if you have to) and tear it apart into a collection of assumptions. Then review w/ your CTO (and other teammates) and ask them how do they know this assumption is true or false, where does their confidence derive from. Get them thinking in this way by asking directly (and politely) from the point of view of “seek first to understand”. In doing so you’ll be getting them to reflect on their decision making and asking the organization to shift from one-off decision making to becoming more intentional beyond (1 customer said they needed it).

It would also be good to ask for each assumption, what do you have in front of you, yourself can use to prove/disprove the assumptions. I.e. what access to analytics do you have? Can you create surveys or run interviews with customers on the fly.

By working on the past feature set you can then create habits that you can apply to the future roadmap conversations.

It is SO hard to work alone in our discipline (any discipline), but especially when ppl really don’t get us who are around us all day long.