Thinking about doing some kind of Earlyvangelist t-shirt for swag or fund-raising for Leancamp. What do you think? Worth paying for? Would you wear something like this? (Tell me like it is – I can take the criticism if you think it’s a silly idea!)

When you think a customer group will have a specific problem that’s painful enough that they’re already looking for a solution, you can validate that through Customer Development interviews. When you need prospects to see it to get it, lightweight paper prototypes can help you learn and evolve quickly. But what about the middle ground when the customer problem/pain isn’t super strong, and showing paper prototypes won’t tell you if they’ll really use the thing?

Christian Blunden’s (@christianralph) team at Lean Startup Machine London had an idea for a social network for reconnecting dog owners who meet while walking their dogs. The crucial thing to test was if dog owners would bite. So they put up poster for a website that didn’t exist, to see if people would tear off the contact information to check later.

A great example of working out your MVP – your Minimum Viable Product! This quickly tested the riskiest part of their idea, whether people care enough to even check it out. And it test real customer behaviour – what they do, not what they say they’ll do. Nice one!

Every process a startup uses operates at one stage of the feedback loop. But lean startup practices have the effect of optimizing the total time through the loop. Practices that are harmful are the ones that optimize our ability to do just one of the three stages well. For example, you can build much faster if you don’t “waste time” measuring. That’s like suggesting you can drive faster if you close your eyes and hit the accelerator. It’s true, but dangerous. The same is true for departmental structures that work like silos. They may work in large companies, but in startups they’re dangerous because they encourage people to improve at their specialized job rather than maximizing learning.

This is a strong example of truly Lean Thinking (not just Lean Startup Thinking) used in practical design research.

A wireframe is meant to communicate and test. You want to do the least amount of work required to fulfill those functions. Anything more is a waste of time and resources.

A simple product change might only require a whiteboard or paper sketch before implementation. A more radical or dev-intensive change might justify more concept, design and usability vetting.

When paper testing, let the type of customer dictate your level of fidelity. You can show a techie-early-adopter a fairly crude wireframe and they will get it. However, if your target is a fashionista, you need to have more polish, otherwise the lack of visuals will get in the way of an honest reaction about the core value proposition you are trying to test.

The more you require the customer to use their imagination, the less you can trust their response, but you still want to look for shortcuts to actionable conclusions.

… In the end, it’s not about fidelity at all. The best mockup is one that serves its purpose with the least amount of work and time require.

I do think Steve would be surprised if we got him to a Lean Startup or Hacker News meetup here in London!

The tendency of people to dictate solutions, rather than the problem that needs solving, has lead some to emphasise that we should put the benefit of the story first. For example, let’s say a fictional printer manufacturer consistently entices 3% of everyone they e-mail, reminding them to check their ink-levels, to purchase print consumables. In this situation, some might illustrate taking a story like this…


As the PrintCo marketing manager
I want customers to register their e-mail addresses
So that we increase the sales of our print consumables

And changing it to this:


In order to increase the number of sales of our print consumables
As a marketing manager
I want customers to register their e-mail addresses

The intent behind this shuffling around is to get people to think about the problem in order of business value first, then the stakeholder then what the stakeholder thinks will deliver the value.

But, the story is talking about a stakeholder… In my experience, this doesn’t get the best value from the user story approach.

Stakeholder ‘stories’ or User Stories?

I’ve found that user stories are most useful when communicating to the team if they encourage a conversation around who the user is, what capability the user needs and why it’s important to the user (could that be why they are called “user stories”?). This helps us to understand what user experience they need and what capability will make that possible.

This is an interesting take on getting to the big picture from user stories, and a useful way of thinking with Customer Development. The post goes into a deeper discussion, so check it out on Antony’s blog. He also has a class coming up at Skills Matter in April: http://skillsmatter.com/course/agile-scrum/antony-marcano-feature-injection-c…