The cart before the horse

“We need a digital strategy to map out our roadmap to success”

“We’ve got to use <insert Content Management System / Product> because we’ve paid for licences for it”.

No you don’t.

You need to think about the what, then just get going on the how.

To overuse the metaphor, you need to stop thinking you need a horse and a cart.  Don’t spend your time  designing the cart, or worse still putting it in front of the horse.  You’ll never get anywhere. Your horse will be perfectly good to get you started on the journey.  If it is an old nag you won’t have invested much time and effort on designing a cart that’s not fit for the horse.  And if it’s a thoroughbred you can build a cart that is fit for the journey when you need it.  And that roadmap? What use is it in uncharted territory?

Lean startup machine and the problem with parallel dating

Can you build a business in a weekend?  Can you take an idea, validate it through customer research and launch it to market in forty-eight hours?  Can you pivot in the process- realise that your proposition isn’t as compelling as you thought to your target market and either fail fast or change direction and build something even better?

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).

Landing page created using unbounce

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.

The phone texting interface

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.

Screen shot of jobstipation

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.

IT innovation can be imitated, great brands can’t. Discuss.

Seen in a marketing presentation “IT innovation can be imitated, great brands can’t“. It’s a great statement that begs to be turned into an exam question with the suffix “discuss”.

What strikes me is this is how a senior marketeer perceives IT; as a commodity with little creative flare and talent. What it ignores is the fact that in truly great brands, IT is oxygen by which they breathe. Facebook, Google, Microsoft.  These are great brands that are IT.

Indeed it is this thinking that that destroys great brands.  Think photography; Kodak (great brand) and Flickr (IT innovation). Think vacuum cleaners; Hoover (great brand) and Dyson (technology innovation).

Enterprise IT has to drag itself out the depths of the organisational cesspool; be recognised not as an enabler, whose customer is the business, but as an innovator and a brand builder. And marketeers need to recognise that without IT, without the ability to execute, their brand will ultimately wither and die.

A tale of two innovation approaches

Last week I attended the kick-off meeting for the UK government’s Technology Strategy Board initiative “Collaboration across digital industries: creating sustainable value chains“.  They have £5.8m (of tax payers money) to award to “Successful collaborators… to demonstrate how their proposed activity improves or creates new value chains and networks, and show where value is to be created from information, content and services.”

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 LeanstartupmachineEric 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.

Guess who? (Kill the Agile Buddha)

Guess who am I now.

I’m in a supermarket, I’m pushing a trolley. I’m putting items into it. I just need some bread and I’ll be going to the checkout. Who am I?
I’m in a bank, queueing up in front a machine for depositing cheques. I’ve got a couple of cheques I need to pay in. Who am I?
I’m in an electronics store. I want a new printer but I’m not sure what’s the best for me, I’m looking for someone to help me. Who am I?

Or maybe what am I?

I am a customer.

Aren’t I?

Business language backs up my assumption. The employee at the supermarket checkout is called a Customer Service Rep, my personal (customer) details are held in the banks Customer Relationship Management system, in the electronics store I’m looking for Customer Support. And after I’ve bought my printer I’ll be asked to complete a Customer Satisfaction Survey.

So everything indicates that I am a customer. Or that is what I thought I was.

Apparently not according to the Scrum zealots.

At Agile 2009 Tom Illmensee presented a paper “5 Users Every Friday: A Case Study in Applied Research”. It describes how an eCommerce division of an electronics retailers introduced agile and how the user experience team adapted to agile. It starts by describing how their initial forays into agile were deemed successful. It was collaborative with the disciplines well integrated; “whiteboard wireframes, minimal documentation, and product demos. Usability tests with paper and semi- functional prototypes were conducted with shoppers each sprint”. More than that, the whole team enjoyed the experience. A decision was made to “take agile to the next level”. The next level was the introduction of a consulting firm who brought in scrum training. The scrum dogma was painful to adopt, but they got there in the end. But there’s a line in the paper that made me angry:

“The peculiar semantics of Scrum were especially confusing at first. In retail customers were people who bought things like stereos and flat-screen TVs. Not anymore. Agile had changed the definition of perhaps the most important word in our business environment: customers were now internal product owners. Customers would now be referred to as shoppers—or users.”

I’ll write that again. Customers (the people who the business depended upon, and “the most important word in [their] business environment”) would now be called shoppers. Or users. Because in agile, customers are internal product owners.

Sorry, these consultants, these agile zealots, these software egos have got too big for their boots. Dan North, pulling to pieces the nonsense of ‘software craftsmanship’ put’s it eloquently:

Software Craftsmanship risks putting the software at the centre rather than the benefit the software is supposed to deliver, mostly because we are romantics with big egos. Programming is about automating work like crunching data, processing and presenting information, or controlling and automating machines.

Software at the centre rather than the benefit the software is supposed to deliver. Software is the means to an end, not the end itself. If a certified scrum master (certified master based on two days training and a multiple choice questionnaire, now there’s a farce) tries to rewrite your business language, tries to tell you that your domain language is wrong, show him or her the door.

There’s a budhist saying “If you see the Buddha on the road, kill him“.

If you see agile in your workplace, kill it.

Why kill the Buddha? because the Buddha becomes an object, your own illusion of what it is. And it this illusion is wrong.  To turn the Buddha into a religious fetish is to miss the essence of what he taught. Killing the Buddha means taking responsibility for yourself.  Same with Agile; to turn agile, to turn software development into a religious fetish is to miss the point of what it is all about.

===

I presented on the customer theme a while ago, here are the slides.

And here’s me narating the slides on google video.

The bus and the beach

“And what if that person was run over by a bus” is the standard question for eliciting whether they are a ‘key man dependency’. If that person was taken out of the system, would the system be able to continue.

Talking about being run over by a bus isn’t the most pleasant language to use.  In a workshop today I heard a far more palatable question.

“What if that person’s six lucky numbers come up? What if they won the lottery. What if Monday morning for them was sipping Pina Colada on a palm fringed beach rather than supporting your obscure system…”

Smart meters. What will happen Vs. what could happen

Smart meters. What will happen Vs. what could happen

Smart meters are the Next Big Thing at the Energy companies.

Over the next 11 years every household in Britain will receive Smart Meters, one for gas and one for electricity. This project will be one of the largest infrastructure projects to have taken place since the Second World War.

So says NPower.

I’m going to get a Smart Meter? Whoppeeedo!

Whilst the idea is compelling to the companies themselves, I don’t see them answering the question “so what” in a particularly compelling way.  They try, talking about “providing you with much more information on your energy consumption allowing you to be more fuel efficient and save money”, but really. So what?

(This calls to mind a quote from Jurassic Park where the Jeff Goldblum character says “Yeah, but your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should”.)

Just because I can control my boiler from my iPhone when I am away from home…. well why should I? What is the point? What is the customer need that smart meters are fulfilling?

That is not to write off smart meters. But what else could they do? What new business models could they inspire?

How about introducing gamification to the way people monitor their energy consumption.  What if the customer could win recognition as being the most energy efficient in their street?  What if gamification could be used as a reward for more energy efficient behaviour?  What if it enabled people to trade their energy usage within their social network?

Lot’s of big ideas but I don’t hold my breath so see anything innovative coming to market anytime soon. Marketing departments may dream of such things but I don’t see them gaining traction when IT are tasked with rolling out functional requirements for mundane, pedestrian and unimaginative use cases.

Yet might there be a different way?

Dear Energy Provider. What if you carve out a niche within the larger smart meter project to build a test and learn capability? A capability that can rapidly develop ideas and take them to market as experiments, product betas. A place where technology is less of a concern than the idea. Many of the usual non-functional requirements can take a back seat as you take the concept to consumers. a place where the idea has to prove itself cheaply for real, or fail fast.

An interesting aside, the way that Mumsnet have developed a community site that attracts 25k per day:

Essentially, we started with a blank piece of paper, viewing ourselves as a platform provider, with the understanding the site had to be developed in collaboration with mumsnetters at every stage.

The most important factor has been letting the community direct progress and listening to what they want – almost all innovations, new site and product developments at Mumsnet are derived from members suggestions.

This happens on a day-to-day basis: we view the site as an ongoing beta or focus group. Most recently this has led to our ‘Off the Beaten Track’ section, covering sensitive issues which which users’ requested not to be indexed by Google. Their feedback and suggestions have also been instrumental to the design of our soon-to-launch mobile app.

What if, instead of rolling out Smart Meters to customers and extolling the virtues of how good the pedestrian things they do are, what if the energy providers derived new product innovations based on the smart meter technology through their customer suggestions.

And thinking more radically, what if they unlocked their data that the smart meters provide and let the community develop innovations (as with the UK government’s Open Data initiative).  There’s lots of new business models, new ways of working. But again, I don’t hold my breath for anything inspiring anytime soon.

Image credit: Todd Smith

Minimum viable mobile app

I was recently challenged by a product owner on how you can deliver a minimum viable mobile app.  Her concern was that she only gets one shot at launching her app on the app store, customer feedback is gold dust and the last thing she wants is to launch a half baked product that will result in a low customer rating.  Good stuff may come later, but if the first tranche of customers rate the product poorly, the product has already failed.

This is a valid concern, however when you review product feedback that consumers give, it is usually around the experience they have with the product shipped, i.e. issues with what it does, rather that what it does not.  Go to the app store and look for apps with really bad reviews. People complain that an app isn’t usable, is buggy, is hard to use (or is just plain ‘bad’). They don’t complain that it doesn’t have features.

Jason furnell recently blogged about the launch of the REA iPhone app. This was built with close collaboration between designers and developers, launching a Minimum Viable Product Minimum Delightful Product  that after a week was #1 in the Top Free Lifestyle Apps Category.

Getting the basic product right and introducing new features ‘enhancements’ later is preferable to releasing a fully featured product that fails to delight.

Rout me a parcel

Graham Charlton wrote a great blog on eConsultancy a couple of days ago on how on-line retailers are managing customer expectations. (Or not as the case may be). He takes it as far as the check out, but what happens next?

The ability for customers to track parcels and delivery is becoming increasingly common.

The requirement is simple. Take the package tracking status (that we have already) and display it to our customers.

The execution of this separates the customer led from the IT led. The former will take the internal codes and language, ditch the codes that mean nothing to the customer and translate the status into words the customer understands. The latter just display the internal codes and status verbatim.  Both deliver the same functional requirements, one delights, one confuses.

Compare the following:

1. BPost: what does “parcel is routed” mean?

status from bPost

2. Royal Mail: “We received item xxxxxxx at [Placename] DO on the 2010-12-22. The item is now ready for delivery.”

3 For exactly the same package at the same time, Amazon track its status as “Latest event: Out for delivery – Dec 22, 2010 4:34:51 AM”

As you’d expect, the eCommerce website does eCommerce the best.

Act like a startup

I recently presented at the AOP Forum on secrets of product success.  Twenty minutes to get through sixty two slides was fun; part of me tells me I need to slow down, be more considered and reduce the messages I want to get across.  Another part of me just says meh!

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.

3 of 38
1234567