Methodology

The product is irrelevent. It’s the customer experience that pays the bills

Why do organisations exist? To make money.  In corporateSpeak “to add shareholder value”.
Where does money come from to deliver shareholder value? Customers.

Many organisations seem to forget this slight detail. It gets lost in the internal machinations and politics.
Why do individual funcitons exisit within an organisation? Marketing, product development, IT, sales, operations… None of these add shareholder value make money in themselves. Yet in all too many organisations these different functions behave as if they exist for themselves, they are entities unto themselves. Each entity may pay lip service to the “customer” but how joined up is the reality?

How familiar is this.

The product team identify the need for something, based on anecdotes from the sales guys, or something they perceive to be wrong with the existing product or a hunch about a potential niche in the market. A niche in the market but is there a market for that niche? A bunch of requirements are written up and an optomistic benefits case is written up. There are x million widget users in the market place. Y% of these would benefit from NewGizmo. We project 10% of these will buy at a price point of £z. The requirements are thrown over the wall to IT to put some development costs on the project. The project has yet to start and a launch date is set in stone. And a project manager has yet to be assigned. Marketing are brought into the picture and tasked with how are we going to sell the product. Development starts (the new project manager is aghast at the scope and timescales he is inheriting). Operations enter the project and throw water on the fire. There a whole bunch of compliance and business as usual considerations that only now come to light. Relationships become tense as the project manager tells the product team that they can’t have what they want by the date they wanted it. The date has been set in stone, so the product team throw out some of the initial requirements, based upon an argumentative workshop on Thursday afternoon (noone bothers to refer back to the initial benefits case, even less any thought of how their decisions impact the overall customer experience). And inevitably a cut down NewGizmo is launched to the market a month late and sales are nowhere near what was projected. What we need is NewGizmo 2.0 and so the cycle starts again…

What if we put the customer at the heart of the organisation.  What if everything we do is motivated by serving the customer?  What if we forget all about our products and focussed upon what our customers’ need and how we can delight them.  What if the products become an enabler to a compelling customer experience, rather than an end in themselves?

Isn’t shareholder value all about generating revenue? Isn’t revenue driven from customers?  Aren’t customers driven by compelling experiences rather than mediocre hassle?

Clarity in objectives

Too many IT projects have vague buzz-word objectives.

  • “Single sign-on”
  • “Legacy refresh”
  • “Migration”
  • “Porting”
  • “Global Tick database”
  • “Unified platform”
  • “Cross channel integration”
  • “Content mashup”
  • “Real-time la-la”
  • “Streamlined processing”

These aren’t objectives. They are recipee for confusion, lack of clarity and focus. Better to think in terms of customer journeys, what is it that an end user want’s to achieve, end to end, and focus on delivering real value to customers, rather than trying to deliver some amorphous, mamouth “implementation” that does a lot of something mediocre, and little of anything great.

The project see-saw

Most organisations have separated their IT function with IT offering their services at a price. There are good reasons for this, but it is not without its issues. Prashant Ghandi has written some good stuff on this. All too often the separation is more a divorce. This manifests itself in the “business” creating projects (hopefully with clearly defined benefits) and throwing them over the fence to IT to deliver. This would not be an issue if the project is founded on a solid benefits case, with benefits matched against project costs. But all too often the relationship is like a see-saw, with benefits and costs bouncing up and down and focus on the business case is lost. Far better to work together in partnership, building the business case together, focussing upon delivering strategic value to customers rather than balancing the project on a fulcrum of mistrust and compromise.

Project in balance

Needs, wants and desires

As a…
I want to…
So that…

The trouble with this story template is that everything is a want. And as I tell my three year old daughter when she says “I want some sweets” I say no! You can’t have them. They’ll rot your teeth!

A story list of “wants” is little more than a feature list. Yes, it may be prioritised, but are we just prioritising “I want a mars bar” over “I want a Twix”?

So how about separating needs out from wants.

When I travelled in Tibet, I needed to go to the toilet. I certainly didn’t want to go… As a junkie, I need a fix. I don’t necessarily want to stick a dirty needle into my arm.

Possibly not the best examples…

I need to login to access my on-line bank account details. I don’t want to log in.

What if we focus upon what our users need to do before including all their low level wants? Imagine the needs are the roots of product that we build, with the wants being the branches. The needs are the outcomes that must be satisfied.

I need to get to Manchester.

As soon as I introduce “wants” I begin to loose sight of my outcome. “I want to fly in an executive jet with Champagne on tap…”

There’s another dimension to consider. Needs and wants may be persona or environment specific.

There’s a half drunk bottle of water lying on the ground.

I’m in the desert. I’m dehydrated. I need to drink it.
I’m on the street. I’ve been to the pub. I certainly don’t want to drink it!

And maybe there’s another expression of volition, that of desire.

I need a drink
I want a glass of wine
I desire a bottle of ’53 Margaux

Maybe there’s something in this…

If you were a bank, which bank would you be?

In the last year, Barclays have rebranded themselves. This is not just a change in the logo (as apparent with NatWest) but a focus on the customer experience. Go into a branch and there’s a calculator on the desk to add up those cheques you are paying in. And a pen to fill out your paying-in book. A free pen. A nice touch – they don’t assume their customers to be thieves and chain the pen to the desk – how much does a pen cost? And put a logo on the pen and you have free advertising.

Free pen at Barclays

On the counter there’s some technology to enable customers to rate the experience they’ve just had. Capturing customer feedback at the time of engagement, better than a focus group at a later date in a stale market research suite.

feedback at barclays

Outside the branch they don’t call the hole in the wall an ATM. They call it what their customers call it. A Hole in the Wall. All these things make me feel warm towards the brand. Brand Warmth is something that marketeers measure. Customers who feel warm towards a brand a more likely to consume that brand. In marketing research, perceptions of the brand can be tested further using word association. “If AcmeBrand was a car, what car would it be?” “If AcmeBrand was a tablet and you took it, what would happen to you?”

I think that we can borrow some of this thinking when we build software. I’ve written previously about emotional requirements – how do we want users to feel when using what we design and build. Before we start on something new, ask the question “how warm do we want our users to feel when using this product?” It’s a useful level to pull; warmth is probably going to cost more.” “If this product was a car, what car would it be?” If the customer says “Ferrari” and we are thinking Ford Mondeo we need to focus on managing expectations. A Ferrari is going to cost a lot more than the Ford. I’d like to know what I’m going to get before I start bragging about the new sports car I expect to soon be parked in my drive.

Customers are not your enemy

Paired programming can be daunting to developers who have not done it before. The thought of some someone else looking over your shoulder whilst you work can be met with resistance. And yet the benefits of the transparency that paired programming brings are well documented.

B2B organisations display similar traits to the developer who is resistant to paired programming. They don’t want anyone looking over their shoulders until they are comfortable with what they are doing. And that includes customers. In my experience, the bigger the “B” and the smaller the “2B” the harder it is to gain access to the people we are developing the product for.

It’s not like this in the B2C world, where organisations understand the need to talk to their customers, to do market research, to test propositions. In the B2B world, organisations become far more protective. There is a fear that if we talk to our customers we will be making promises that we cannot keep. We will be building expectations that will inevitably be broken. In the B2C world you can show what you like to customers, if the final product bears no resemblance to the ideas we’ve tested in focus groups it doesn’t matter. The conversation with the customer is part of the process. We do not assume any “customer memory,” indeed the fact that we have explored different ideas and propositions with customers is seen as a positive; it can feature in the PR associated with the product release. If you release a product to market that looks nothing like what you’d explored in early focus groups it really doesn’t matter. You are selling to a segment that is bigger than a focus group of 12. But what if you customer base is small. What if there is a customer memory, that the people you test propositions with are the people we depend on selling to. The people who will keep us in business. In such a scenario it is understandable why you become protective of your ideas and fear saying anything to your customers until you are confident that you can deliver it. Trouble is, by that stage it may be too late. You are committed to a path of action that can be costly to change. What is required is some transparency and honesty; creating a dialogue as early as possible.

So here is the challenge for B2B organisations with a small, high value customer base. Open yourselves up. Be honest, open and transparent. Web 2.0 is all about collaboration and social networking. That shouldn’t just be about me sharing my photos on flickr, my videos on YouTube, my bookmarks on delicious. Product managers should be blogging about what is happening on the product they are developing for their customers. Customers should be commenting on the progress that is being made; they should have a direct channel to the development team, not via layers of corporate Chinese whispers. Here’s a challenge to the business in B2B organisations; get blogging. Stop fearing your customers and worrying about failing to meet what you perceive them to expect. Once you are transparent to your customers and proactively manage their expectations you can venture on a more successful and profitable journey as partners, not as adversaries.

Parsimony and the golden plate

A general principle in science is that if there are two feasible explanations for a phenomenon then you will take the most parsimonious, the simplest and most elegant solution. Agile software development takes a similar principle, do just enough focussing upon what is truly needed. Practitioners of the methodology will recount with pride how they have worked on projects were the “customer” required A,B and C. They’d planned for eight iterations, but by the sixth iteration they’d delivered A,B and half of C and the customer was happy; the software met the customers requirements and was delivering business value. There’d be diminishing returns by carrying on any further; any more work would be “gold plating”

“Gold plating” in software development is a concept that is frowned upon. Doing more than is strictly necessary breaks the theory of parsimony; if it is not going to demonstrably deliver value then it is gold plating and is to be given a low priority. More often than not gold plating is seen to be “scope creep”. This is often manifest in agile projects when requirements are deliberately vague at the outset of the project. Why invest time in specifying requirements that will undoubtedly change as the project progresses? The problem is that the developers’ idea of how a solution will be implemented will be the most parsimonious solution whilst the customer has a more complex idea of how a feature will be manifest. The requirement is the same, yet what the customer actually wants is gold plating and scope creep. Let’s explore this with an example outside the software industry.

Imagine a product in development. It’s hi-fi comprising of separate amplifier, CD player and speakers. It is to be sold as a package (yeah, development is iterative and each component could be a release, but that is not the point here…) We are going to need to connect the CD player to the amp. We can express that as a story:

As a customer
I want to connect the CD player to the amplifier
So that I can amplify my music and listen to it through speakers

OK, so we need some interconnect cables. Using our experience of connecting amps to CD players we picture this:

phono1.gif

We know what it takes to make one of those cables because we’ve made them before so we can accordingly put an estimate to this requirement. Trouble is, for this scenario it will be wrong.

Return to the opening statement, “imagine a product in development”. There is a whole wealth of information missing in this statement. There is more to the product than it’s physical construct. We need to consider the context in which the product is to exist. In the world of interaction design this is contextual analysis.

Numerous factors may have an influence on the development of features. Start with the competitive landscape it will play in. When placed against competitor products, what is it aiming to do, is it going to meet a need (the CD player just plays CDs); are we looking to achieve competitive parity (we will match other features that are standard on our competitors products) or is the product goal to exceed expectations and become the market leader (it will offer superior sound quality and the ability to play MP3 files).

Who is the target market? In our story we stated “as a customer”, but who is the customer? Is it mass market or niche audiophile?

In addition to the business objectives which are critical to drive forward the project, (i.e. launch the new product to increase market share) the product objectives should also be considered. For our hi-fi this is “great sound for the budget audiophile”. Once we have this we can attribute emotional requirements to the product. How will our target customers expect to feel when they use the product. What emotions should it elicit? For this product let’s assume “high quality” and “simplicity,” rank highest.

With this background, when we return to the interconnect requirement, it is clear that the original assumptions are invalid. Our assumptions were based upon a mass market solution achieving competitor parity. In fact we need to aim a little higher, our customers are more discerning, the product is to be marketed as high quality audio and we are looking for the product to be an award winning design. So those interconnects? We need to gold plate them. The story will actually manifest itself as this:

phono2.gif

Mmmm. Gold plated interconnects. Gonna sound good!

Now the real world

Let’s take a requirement from the banking world. It’s a system that allows users to trade equities; to buy and sell shares.

As a user
I want to select a UK equity
So that I can see its current bid / ask price.

At its most parsimonious our acceptance criteria (i.e. how we will know this requirement is complete) are as follows:

Given the user enters the stock RIC code
When the chosen stock is valid and tradable
Then display the bid/ask price of the stock

Given the user enters a stock RIC code
When the RIC code is not recognised, the chosen stock is invalid or untradable
Then display an error message saying “RIC not valid”

But is the most parsimonious solution the right one? We can only answer that once we have carried out some contextual analysis. For professional equity traders, who know RIC codes and speed is of the esscence then the implementation implied in the acceptance criteria is correct. But if the stock look-up is a new feature on a retail banking “portal”, extending the banking offering beyond balance and transaction reporting and making payments, to include share trading for a “mass market” audience then the implementation falls short of what is truly required. In this scenario the feature requires gold plating. This may include

  • Searching on company name in addition to RIC code
  • Meaningful error messages
  • Help text, content managed.

If the requirement is to have a “world class” share trading system we may need even more gold plating:

  • Narrow search results as the user types in letters
  • And so on.

If we turn to business value, it is hard to ascribe business value to the gold plating of individual features. Instead we should explicitly state up-front the emotional requirements that will “bloat” features beyond the most parsimonious implementation and inflate our initial estimates accordingly.

Upfront is good

Let’s get a few things straight.

  • Analysis and documentation are not synonymous.
  • “Big up front design” (the agile zealot’s hell) and analysis are not the same.
  • The holy grail of self documenting code (“the code is the documentation”) means bugger all to people who ask for the software to be built in the first place (people for whom a class is something they went to school in).

The Agile Manifesto states “Working software over comprehensive documentation”. Note the use of the word “comprehensive”. It doesn’t state “working software over documentation”. It also states (and this is all too often forgotten) “That is, while there is value in the items on the right, we value the items on the left more”. It is essentially pragmatic, do just enough that is necessary to allow you to be successful. This is most important in the field of analysis.

On all but the smallest of projects where you have a customer who knows exactly what she wants, is available at a moments notice to the developers and can communicate a clear vision to all involved, you are going to have to invest in some analysis. I’m not talking about writing-a-bunch-of-stories-analysis, I’m talking about understanding the business context, producing a product statement, segmenting customer needs. Maybe it is crafting an aspirational visual representation of the end product, wireframes, an information architecture, an imaginary product “fact-sheet”.

I’m not saying do reams of analysis for the sake of it. I once worked on a government project where I spent three months specifying requirements and designing business processes for a scheme that was inevitably going to change when new legislation came out. That was stupid. Just enough analysis is not only volume and content, but also its timeliness. It would have been sufficient to identify the broad scheme requirement as something in the pipeline with the detail to be fleshed out when it was required. That way we would know about it up front, and act upon it when required.

Developers are smart people, they don’t want to write code for the sake of it. They ask questions, why are we doing this? “Individuals and interactions over processes and tools”. Nothing in that line about not using documentation. Just the right type of documentation to help facilitate the conversation. “Individuals and interactions” lack permanence – the business guy doesn’t want to explain the who’s and why’s to every new developer that comes to the project. They expect to state the project background once and it to persist through the project. (Ask a business guy to repeat this stuff more than once and he’ll soon get annoyed).

Bottom line: Do up front analysis and be proud of it. Make it just-enough in a format that is appropriate (so why is it suddenly OK that it is on the Wiki rather than in a Word document on the corporate LAN?) Get it out there!! Stick it on the walls, let everyone see the business objectives, who the users are (personas), the competition, the wireframes, the product mission statement.

Ditch the feature shopping list. Think customer journeys.

Let’s imagine a mobile phone provider that that has an on-line presence as well as a high street retail network. Their current website was built several years back on legacy technology; it is slow and has a conversion rate lower than industry norms. Along with having poor usability, the current shopping cart functionality does not support the concurrent usage figures that are hitting the site. The business takes the output from their web metrics and throw these at IT and demand improvements. And a new IT project is born. Rebuild the existing site on a new platform. They get a design agency to handle the look and feel. The functional requirements are built upon the existing functionality and chunked into functional silos:

  • Content managed brochureware site
  • Phone selection
  • Tariff selection
  • Shopping cart
  • Order management

A typical project process. That is flawed. It is starting with a functional premise. An alternative is to think in terms of the customer and customer journeys.

We can start by asking who the customers are. Almost certainly the marketing department has a customer segmentation model – this is a good place to start. That may give us basic attitudinal and behavioural details on customers, but we need richer data. How do customers shop for phones? So we go and spend time in the stores and observe how people buy them. It soon becomes clear that the choose phone – choose tariff buy model is a journey that is only taken by a certain number of customers. Other customers come into the store with intentions – they don’t know what phone or tariff they want, but they know what they want a mobile phone for. Other customers come into the store asking lots of questions, they are doing research; they leave the store with the sales guy’s number, and costs for a couple of phones and tariffs. We look at the competition and see how they sell phones. We look at Amazon and eBay and expedia and see how other retailers sell products and experiences on the web. We synthesise our research and suddenly we have a whole bunch of new requirements. Gasp! Scope creep. Indeed if we list them out into functional silos again:

  • Content managed brochureware site
  • Lifestyler phone selection wizard
  • Save a quote
  • In-store quote save for on-line fulfilment
  • On-line purchase for store fulfilment
  • Phone selection
  • Tariff selection
  • Shopping cart
  • Order management
  • Etc

The business is excited and IT is despondent. When the business announce the date all this must go live by, the letters of resignation land on the IT directors desk and they start looking for contractors. It does have to be this way. You can have your cake and eat it.
Rather than thinking about vertical functional silos, we should think about horizontal slices through the functionality. Slices that support customer journeys. We can start with simple journeys to start and build complexity as we prove our process and new platform, mitigating technical risk as we progress.

don't functionally silo, slice by customer journey

The first release probably needs to demonstrate the new platform works: we can deliver on time; that a new shopping cart interfaces with our legacy warehouse order management system; etc. What’s the bare minimum we can do that does this and delivers business value. How about a microsite that sells a single product. Customers are directed to the microsite via a URL published on a flyer handed out in the stores.

As a customer who has picked up a special offer N80 deal flyer, I want to buy a Nokia N80 on a pay as you go contract

Our acceptance criteria:

Given I enter my personal details and credit card details When my credit card details are validated Then send order to warehouse to dispatch phone and activate contract.

We can decompose this requirement into discrete requirements, “stories” of sufficiently small size and estimate them. We’ll soon get a project velocity and because it is only a small release expectations, risks and dependencies will be easy to manage. We’ve not had to wait for months to get something out, everybody is happy.

We identify that a profitable segment of the market are the aspirationally clueless. People who want a mobile phone, realise they are a minority who don’t have one but are too afraid to admit they have no idea what they want. So we build a new customer journey.

As an aspirationally clueless I want say what I do and how I live my life and have a suitable phone selected for me.

OK, not the finest story, but you get the point. This story might take elements of the phone selection and tariff selection functional silos, but just enough to realise the required functionality. Because we are building around customer journeys, just enough to realise customer intentions that support those journeys we build only what is required. We are not building by feature list. We don’t over promise and under-deliver. We are building trust with all stakeholders. Surely this is the better way to build software, thinking about customer intentions and incrementally delivering to support more complex customer goals. Sadly, people all too often get fixated by feature lists. Because that is what they are used to. Because that is how products are sold. But isn’t there a marketing 2.0 where we sell experiences and go beyond the product. Isn’t that what Virgin does? But I’m probably off on a tangent.

Getting attached to stories

The physical manifestation of agile stories are a description of the requirement (in the form “as a [user], I want to [goal], so that [reason]”) written on an index cards with the acceptance critiera written on the reverse. The developer can pick up the card and work with it. Once the acceptance critiera are met it can be put in the pile of completed cards. If at any stage of the process we are not happy with the card, given that it is only a “promise for a conversation,” it can easily be torn up and rewritten. Tearing up cards is a powerful statement. We don’t like what we’ve written? That doesn’t matter, rip it up and start again. That works well in the opening stages of a project, but sooner or later the cards will be copied into a spreadsheet and this is where the problems start. We become attached to the story; good project management discipline demands we keep an audit trail of what we do. Suddenly it is not so easy to rip up the card. Maybe the initial story did not truly represent the requirement. More often than not the story title, and detail will remain the same, but a notes column will be spawned in the spreadsheet and the change to the story will be entered as narative in this column.

Clearly this is not a satisfactory way of doing things. Part of the agile coaching process has to be around the flexibility of requirements, and this includes refining, rewriting and splitting stories as the project progresses. The underlying scope of the project will remain the same, however inevitably the estimates will change. This is often difficult to accept if you are versed in traditional project methodology. At the beginning of waterfall projects you have certainty, clearly defined requirements and a plan to guide you by. It is towards the end of the project where deadlines slip, scope is managed by change requests and IT is cursed as being unreliable, untrustworthy and the breaker of promises. The reverse is true with agile. There can be a whif of unreliablity in the early stages of the project, particulalry if there is no clear plan. This is excerated with an excel storylist that changes by the day. The difference is that you are more likely to succeed in delivery when going with the agile approach.

Agile Vs Waterfall uncertainty graph

The bottom line has to be an acknowledgement that there will be pain during the opening weeks of a project. Stories will be ripped up – delete them from the spreadsheet and don’t bother to keep an audit trail. Agree that the story list will be in a state of flux for the first few weeks. And once the project is settling down, once we have a better understanding of the project and are happy with stories, only then should we use formal PM tools with confidence.

8 of 11
4567891011