Eric Reis has written about Lean Startup Machine in a blog that suggests you can.

Inspired, I travelled to NYC over the weekend to experience what Lean Startup machine is all about. I was blown away.

Here’s what happened.

The event kicked off at 6pm with networking then presentations on Lean startup and what it is all about.  Anyone who had an idea was given a minute to pitch to the group.  These were voted on and the best 12 ideas were selected.  People self selected the team they wanted to join – six per team.  The team I wanted to join had seven people, rather jet lagged I agreed to leave and move to an under-resourced team – at the time not my first choice of product to start up, but oh what fun it was to be.

First step was to document our hypothesis and assumptions. Our hypothesis was that men and woman who are active daters have problems with remembering / keeping track of their dates.  The customer value proposition was essentially a dating CRM system.  So I’m happily married so not the most obvious of product choices for me, but this is what the weekend was all about; coming up with a proposition and challenging it.  With a clear hypothesis, at midnight we hit the streets of New York to test it on our target market.  Interviewing people in the lines outside clubs and on the streets around we sought to understand whether there is in fact a problem.  We assumed that people date many partners at the same time and that they would be open to a system to help them manage their relationships.  Our hypothesis was partly proven, there’s clearly problem that is felt more by men than women.  Any solution would be targeted at men.   There are workarounds that men use, for example using fields in their phone address book to capture data such as place met, key features.  And the more ‘advanced’ parallel dater does indeed have a “little black book”.

To back up the qualitative data we built a surveymonkey questionnaire.  This would further validate the concept and capture insights into what data parallel daters need to remember their dates.  To drive traffic to the survey we planned on using Amazon Mechanical Turk to place ads on Craigslist personals through the night.  Unfortunately on Saturday morning both services had rejected us so the survey didn’t get as many responses as we’d have liked.

Our first Minimum Viable Product was a landing page using unbounce. A little more than twelve hours after the initial concept being pitched we had a product, live in the market.  BeBop was born (another variant was datingCRM was also launched to test the URLs and the effectiveness of the calls to action).

At this stage the product was a landing page and a call to action “I’m interested”.  Clicking on that took the user to a form that included an email capture address and an option to sign up to the free version and to be notified of the paid-for ‘pro’ version when it comes available.  This way we could judge if the idea would easily generate revenue.  (All the people who completed the form indicated an interest in the $5 a month version).  The idea was to drive traffic to the landing page using Google adwords, but google didn’t like us and this was denied as well.

With our learnings from the previous evening’s customer research we did some design thinking.  The team sketched up ideas of how we could solve the problem.  This exercise was repeated six times – people are precious of their first design, by the sixth they are clutching at straws and this is when left-field ideas can brew up.  And it did.  Why did the product have to be an application?  We’d seen some non-smart phones the night before; an iPhone on Android app would be of little utility to some of target market.  What about an SMS texting service.

Pivot.

The afternoon was spent building a texting service based upon the Twillio platform.  Customers could text their name to a number and they were signed up.  All they they need do is text the contact details of their date to the service and it would be stored.  They could retrieve it by sending a message “info: name” to get that contact texted back to them.  We included some gamification to encourage usage.

Saturday night and we hit the clubs and bars again.  This time putting the concept into the hands of potential customers as well as handing out cards with the telephone number.  More customer research.  More often than not our target market was with women, so it was hard to gauge interest.  One guy pretended to throw away the card when the girl he was with expressed shock at the concept – with a slight of hand he tucked it into his shirt pocket as he brought his hand back.

Sunday morning and we reviewed the results.  Some vanity metrics – 150 cards handed out, around 50 meaningful conversations with more customer validation, 15 sign-ups and 7 messages sent.  Was this success?  Hard to tell.  We’d also built a basic MVP android app that we launched Sunday morning and the next step is to test this MVP with customers (the issue we had is that our target market is best found at night so customer testing in the daytime would be hard).  We talked about pivoting again and exploring taking the product to a wider market – do people with non-smart phones have problems managing richer contact details other than just a name and number?  One girl who’d seen the datingCRM product said that she’d use it for that.  But by now time had run out to test this new idea.

Three thirty on Sunday afternoon and each team had six minutes to present with three minutes of questions.  We were first.  It went well.  But how did we do?  We came third overall and joint best MVP.  But it wasn’t the competition it was about, it was more the experience.  It was a real privilege to work with such talented and smart people.  David Young-Chan Kay, Yan Tsirklin, James Washington and Mikhail A. Naumov were an awesome team to work with.  More than that, the whole NYC startup movement is infectious and inspiring.

It didn’t end with our presentation.  There were some other, awesome startups with even better stories that were hatched over the weekend.

One team started with a hypothesis around supporting people hook up with mentors to help them choose the right career path when they were starting out or unsure of the path they are on.  The concept bombed with both the target market and mentors.  In an hour of desperation they realised there was a common theme they were hearing.  People love to bitch and moan.  And thus on Saturday night jobstipation was born, an anonymous place to vent fury and angry about your workplace.  When they presented, ideas of monetisation and tying the concept back to their original ideas were suggested.

The team that won the weekend worked on the hypothesis that teachers spend a lot of time prepping classes, that they spend a lot of time searching for decent materials on the web and that they’d pay for a service that would provide them with quality teaching materials.  Research with teachers validated the assumption that teachers spend a lot of time (thirty hours a week) preparing for lessons.  But the idea that they display economically rationale behaviour was refuted.  Teachers would not pay for the service.  But their principals might.  Pivot.  The team asked the teachers for examples of lessons they have hassle preparing for – geometry was one example.  So they built an MVP that demonstrated searching for quality geometry resources.  They trawled the web to find the information and on sunday morning called the teachers again and showed them the website they’d built.  It may have been ’smoke and mirrors’ but it worked.  The teachers loved it sufficiently to recommend the concept to their principals – the people with money who would pay for it.  All this in a weekend.

In plainer English, they are looking for companies / universities to come together to develop new digital products.  They talked about “pipes” (the ISPs), “Poems” (the content) and “people” (customer demand), with the sweet spot projects being at the interaction of all three.

Last Monday was the kick-off and the competition (document filling) starts on 14th March.  The funding will not be awarded until 19th August.  Five months before any innovation actually starts.  The funding is to support projects that “are expected to last 12 to 24 months”.

During the kick-off, attendees were invited to present their innovation product ideas.  These were then voted upon.  None were particularly earth-shattering (but then I suppose no-one was going to be putting their best ideas forward in a public space).  Moreover, none of them seemed to justify this long and over-engineered process.

Now compare that with this story.  Following the floods in Queensland, Australia, on a Thursday afternoon three ThoughtWorkers  came together to build a product that would support a Government Telethon to collect donations to help the flood victims.

They had “a little over 48 hours to develop, test and deploy an application that was expected to handle thousands of users. Not only that but an application that, should it fail, would prevent millions of dollars from reaching the people in need in Queensland.”

On Sunday the Telethon aired.   “720 requests per minute… with fast response times…  In about two hours [they] had over AUD$2,000,000.00 (two million) donated through [the] website”.

It has gone on to raise over $25m.

Another story.  Another 48 hours.  This time Leanstartupmachine.  Eric Ries has a great write up on it. Teams get together and in 48 hours strive to get a customer validated product to market.  In some cases this meant ‘pivoting’, discarding the original idea to focus on something else it spawned.  (Flickr is the classic example of this, it started out as an online multi-player game, but the photosharing proved to be more feasible and the game was ditched).  Eric writes:

In one notable case, a team was able to conclusively invalidate a business that I have been pitched by venture-backed entrepreneurs many times – with a full day to spare. Compared to entrepreneurs who’ve blown millions of dollars pursuing the same vision, this is a way better outcome. Since they had extra time, they tried a pivot into a much more promising idea. By the time of the judging, they had an MVP in the market with real customers signed up.

The UK government has the best intentions with the Technology Strategy Board.  But do they need all the process?  Why can’t they do what these two case studies did?  Indeed it’s the same with most large organisations, innovation is rarely rapid in the way it could be.    Bring on the entrepreneurial enterprise that nurtures a culture of rapid experimentation, test, learn; confidence to fail and desire to invest in the successes.  Bring on Lean Start Up thinking into the enterprise.

I ended the presentation with the below takeaway slide that is worth replaying here.  I believe that product owners need to start thinking more like entrepreneurs and their seedling product ideas more like start ups.

Think big: Start with a big picture, a vision, where you want to get to. This should be unconstrained thinking, divergent thinking before converging on the specifics.

Start small: Easier said than done, but this is the getting to a minimum viable product.

Fail fast: Get stuff to market quickly, test with your consumers and be ready to fail. If you fail early you fail cheaply. Realise that you have customers, users who are already passionate advocates of your brand. Take them on the journey of development with you. You not assume that everything you need to take to your customers must be polished and perfect. Don’t underestimate the positivity than can be accrued by engaging users in the development process

Grow success: Do not see the end of the project as the end of road. Getting to a first release is only the first step. Successful product owners will be engaged in a virtuous cycle of continuous design and continuous delivery. They can come up with an idea, a new feature and get it in to production in hours, or days rather than months.

FlickR started its life as a tool in a role playing game.  The game was not successful and ultimately shelved (fail fast) with the photo sharing capability being developed; the team realised where the value was rather than sticking to a failed big up front plan.  If you go back in time to 1999 and look at how google described itself:

Google Inc. was founded in 1998 by Sergey Brin and Larry Page to make it easier to find high-quality information on the web.

Nothing there about browsers or phone operating systems or word processors or spreadsheets.  Twelve years to go from a search engine to the Google we know today.  Place that lens over most enterprises and how have they managed to adapt to the changing world?  I know of several enterprise projects that are three plus years in, (that’s a quarter of Google’s life) and have still yet to start delivering value.  You don’t get that with start-ups, or places where vision, passion and personal investment drive the product strategy (thinking Apple and Steve Jobs for example).

I’ll lay the fault at Enterprise Culture.  Silo thinking and career progression through the ranks.  So an individual is personally invested in delivering documentation that specifies the system.  When she delivers these she is done.  What happens next is someone else’s problem.  Reward is rarely for delivering the overall vision, why should it?  How often do all stakeholders involved in a project have a strong grasp of the what’s and why’s of what they are doing?  They are only rewarded on the how they deliver the fragment that they are responsible for.

When IT becomes a supplier rather than a partner, no-one has ultimate responsibility for delivering a coherent holistic vision, it becomes a contractual relationship rather than a passionate obsession.  Funding projects is all to often a charade and a nonsense.  The business submit their funding requests (a line item for a potential project) for the forthcoming financial year in the autumn / winter.  Budgets are finalised in the Spring with the new financial year and months have elapsed due to internal budgetting and accounting formalities rather than the ability to respond to the market.  Contrast that with the start up model with seed funding to get started and if the projects shows viability second round funding follows.  If the project is not viable it is suffocated before wasting cash.  (There are interesting perspectives on this leaner model at Beyond Budgetting).

I wonder if in these lean times we are going to start seeing lean thinking applied to enterprises and a start-up culture being nurtured.  There is certainly a growing interest in agile, beyond the practitioners and from C level executives.  But agility in software development is only the first step.  To be really successful it needs to spread through the whole organisation, not just paying lip-service to the word “agile”, but devolving responsibility to individuals and collaborative, cross-organisation teams who can share the vision, passion and are personally invested in getting the right quality products to market at speed.

Agile is messy.  It is untidy; it clutters desks and dirties the walls.  Progress is not hidden in spreadsheets and gant charts in Microsoft Project.  No, it is on the wall.

Walls are central to agile.  Indeed any visual thinking process that uses ‘information radiators’ as central to communicating information (rather than circulating documents) will make use of walls, sticking cards, posters, post-its, stuff up for all to see.  When you start to use walls, good things happen.  Other people become curious, they walk to wall, they look and see.  When you have wireframes stuck to the walls they go arrrr!  that’s what you are building! There is a palpable excitement, a buzz to organisations who start (and continue) to use walls.

That is, until the detractors come along with demands to tear down the wall.

These usally take one of three guises.

The first, predominantly found in financial services is compliance.  Increasingly clear desk policies are being rigorously policed to ensure documents are not leaked between departments and this often finds its way onto the information radiators.

The second is facilities management who seem to think that their clean whitewashed walls are delivering greater value to the business than anything untidy that is stuck on them. Their knee-jerk reaction is to ban the use of blue-tack and get a whiteboard permanently drilled to the wall to hold the cards.

The third and final detractor is the IT manager who is dazzled by technology and insists on using technology to solve the problem.  Out goes the card wall and in comes a plasma screen with an excel spreadsheet displaying the cards.  This completely misses the point of the wall, of the human element.  Richard Durnall tells the story of his experience at Ford where they employed a technology based process for managing inventory at the plant.  ”Unfortunately this process had a problem; it was rubbish.”  He contrasts this tech-centric system for that employed by Toyota:

When the guy on the line started a new box of parts, he’d take a card off the top and put it into a letterbox. Every 10 minutes or so another guy would drive around in a little truck and collect up all the cards. He’d then go to an office where he had a card sorter connected to a computer. He’d put the cards through the sorter, which at the same time sent messages on usage to the supplier network, and then he’d go and fill up his truck based on the cards that he had, returning the cards to the boxes.

Managing inventory with cards.  Using paper in a paperless office; not everybody gets it.

Knowing that you will have detractors to the paper walls is a first step in managing expectations and getting everybody on board.  Talk to compliance, facilities, and let them know what you are doing.  Ensure an executive sponsor can override any petty bureaucratic blockers.

And before you know it, the information radiators will have moved out of IT and into the way the business manages its tasks as well.

When you are building a product, you get a usability company in because you know that usability is a good thing that you want to have. If usability companies are the critics, what are you expecting?

The first usability test I ran was in 1991. I’ve set up usability labs, I’ve observed hundreds of people interacting with technology and products. My passion has always to do things at speed, turn around results ASAP and engage all stakeholders in the process.  But I’ll talk about that in a later post.  For now I’ll draw on experience of working with organisations that have commissioned usability companies to review their products.  I’ll breakdown the process I have often observed from usability testing vendors, considering both the elapsed time and the actual ‘value added time’ taken.

Day one

The client (usually the business) engage the usability company to audit the usability of the product that is being developed. The consultants will come in and understand the user tasks, roles and goals; the target audience will be identified for recruitment. ‘Value added time’ = 1 hour.

Day two

The team go away and produce a test plan and a recruitment brief for a research agency to find participants. They promise to get it back to the client in a couple of days. They contact their preferred agency who set about recruiting people (let’s assume this is a simple brief for a retail website targeted at young mothers).  Produce test plan (value added time = 3 hours). Send to client for review.

Day three

Client return test plan with a few comments. Update test plan. Value added time = 30 minutes.

Days six-ten

Twelve usability sessions, each an hour long, they do three a day, that is four days of testing. Value added time = 12 hours

Days eleven – thirteen

The team spend three days analysising and synthesising the results, pull supporting video clips and produce a detailed report. Value added time – 15 hours

Day fourteen

The client sees the report for the first time. (Value added time = 2 hours). Interesting results. (IT representation were not invited, they did not commission the report, the product owner wants to see the output first before sharing it with IT).

Day sixteen

The product owner informs the dev team of the changes that need to be made in the light of the usability report. Project manager sucks air through his teeth and says “you’ll need to raise a change request for those items… ha! quick wins they say? hardly… Hmmm, OK, change the labels in the field, we should be able to do that…”

Value added Vs. Elapsed time

The usability company has delivered and their engagement is complete.  From the start of the process to the recommendations hitting the developers who must ultimately action these, for this not-too-fictitious scenario sixteen days have passed, of which only four were spent on value-added tasks, actually doing stuff.

Day n

The product goes live. The usability company are aghast that so many of the changes they reccomended have not been implemented. They place the blame fairly and sqaurely at the door of the developers and reinforce their belief that IT just doesn’t listen, or worse, care about usability. The critics have critcised from their armchair, like the pigs and chickens they are the chickens, participated not committed.

Usability rant part 2>

In his recent update on the progress of the petition, Rob Bowley mentions the Rural Payments Agency project.  I can’t attest to either have been an ‘expert’ or to have had a salary anything near what he mentions, but I was a consultant on that project so nod in informed agreement.  That experience gave me a benchmark to compare ‘bad’ ways of going about an IT project to compare with the ‘good’ world of lean and agile that I now inhabit.

Please sign the petition.

Today we are looking at a large UK supermarket stock control system.  At the end of the day the staff mark down prices on the short-life items (sandwiches etc).  They have a hand held scanner with a belt printer.  Scan item – print label – stick label on item.  Well that’s what the process is supposed to be, only this takes time (20 seconds per item) and when you have a whole shelf to do is a chore (12 items takes four minutes).  Far easier to just write down the new price on a ‘discount label’ with a sharpie and stick it over the barcode (do the whole shelf in less than a minute).

Where’s the problem in that?  In fact three minutes of waste (waiting time) has been eliminated.  Only it is a problem…

The customer takes the item to checkout and the mark-down label is covering the barcode.  The checkout colleague tries to peel it off to scan, but it doesn’t peel cleanly.  So she manually enters in the SKU. And the mark-down price.  And this has taken 2 minutes for one item and the queue has grown and because of the ‘one in front’ policy they have to open a new checkout and suddenly that small problem at one end of the value chain is replaced by a bigger costlier one at the front end.

But had we not observed this we would never know that bulk price mark-downs on the hand-held device is not a nice to have, it is million dollar requirement.

This piecemeal approach extends to larger initiatives as well. In refreshing the website or developing new digital channels such as mobile and TV, IT will typically build out features and functionality prioritised upon their perceived individual business value regardless of what the sum value of the proposed release is. (Focusing all your effort of building functionality that delivers to your bottom line will seldom be as successful as you predict if it is not supported by features that meet the customers needs).

So when it comes to thinking about new features and functionality, where’s the best place to start? I’d suggest collaboratively, thinking around the customer. Collaboration is important to ensure that everyone starts with the same vision. It needs to be shared it with the broader audience, the product teams, IT; anyone whose day to life life will be touched by the project when it starts. I’d argue that you cannot start this soon enough. You don’t need to spend time doing analysis, interviewing all stakeholders individually, coming up with a document that is circulated and reviewed and re-written (with all the delays and waste that such a process incurs). Start the process getting all those stakeholders off-site for an afternoon and get the thoughts out on the table.

Commence with a presentation that introduces thinking in terms of customers and customer journeys. The below SlideShare presentation does this for the airline industry, addressing a new customer experience across channels. I acknowledge that it is pretty simple and doesn’t touch on half the ideas that airline executives may have. That is the point, it is just enough to get people thinking about different customer types and their touchpoints without getting bogged down in detail. This is what we want the participants of the off-site to share.

Once we’ve been through the presentation we break out into small groups a, each taking an individual customer (or persona) and build up a story; a day in the life of… (It is important not to forget the internal users of the system). These breakouts last 15-20 minutes with ten minutes for the team to play back their findings. As they build out a richer picture of the customer interactions they are asked to sketch out what the user interfaces may look like. The process is rapid, intense and iterative, but always focussing upon the customer journey; how will the customer realise their goals. When the teams tell their stories an analyst captures the essence of the requirements on index cards. The final exercise is to lay all these cards on the table and ask the team to group them into similar areas then prioritise them according to their perceived importance. In an afternoon you will have achieved four things. Firstly, you will have captured a vision for the new product in less than a day, with all stakeholders understanding not only the vision itself, but also the process that developed it and the concerns and issues that different parts of the business have with it. Secondly you will have an initial prioritised roadmap for its development. This will change, but it is a good strawman to circulate. Thirdly you will have introduced all the stakeholders together – projects succeed or fail based upon the strength of relationships and getting people engaged from the start will go a long way to creating shared ownership. And finally you will have generated energy, engagement and traction; to do the business case and to get the project started, recognising that just one part of the business having a vision is not going to bring it to the life that they dream.