Work

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

  • Friday, 17 November, 2006
  • By:

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?

Needs, wants and desires

  • Thursday, 9 November, 2006
  • By:

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…

Upfront is good

  • Tuesday, 24 October, 2006
  • By:

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.

Imagine a customer journey…

  • Monday, 23 October, 2006
  • By:

Imagine.

I go into a store and a salesperson helpfully shows me the product, but I’m not yet ready to commit. She offers me a great deal, I’m tempted, but I want to check it out on the web. She says “great!” scans the products and prints me of a personal card with a short unique identifier and a unique website URL. I search the competitors, the salesperson was right, she was offering me a really good deal. So I got to their online shop and enter the URL and there is the tailored deal that the salesperson told me about. It has even got her name on it (so I know he’s going to get some credit for the sale). I get through to the checkout screen. I enter my personal details and I’m just about to buy, but I’ve got a question about the terms and conditions so I take a pause in filling out the form. There’s a number on the website and I get through to the call centre. I don’t have broadband so I loose my connection. The voice at the end of the phone knows who I am and where I am up to. I’m ready to commit… but she apologises, she doesn’t have any in stock. I’ll have to wait seven days. But I could pick it up from the store tomorrow if I want (or even a store close to where I work) or I can get the store to deliver if that would be more convenient. I’m delighted. The next day I go to the store and it is waiting to me. The sales person smiles. She didn’t take my money, but she ultimately made the sale and she’ll be rewarded for it.

Fantasy? It shouldn’t be. Thinking in terms of the customer experience and the customer journey is only the first baby step. The giant leap is to get IT bought into it and implement a solution that is not going to cost the earth and take years to (not) deliver.

And that’s where ThoughtWorks comes in. We thrive on getting everybody together and using creative, collaborative and highly visual techniques we quickly get everybody to consensus on the vision we want to move forward on. Because we are an IT company, we understand the opportunities and constraints with technology. But most importantly because we use lean and agile techniques to delivering technical solutions we are responsive to change, flexible with emerging requirements and can focus on getting things done – the baby steps – whilst working towards the giant leap that will win lifetime value for customers. Hmmmm. That’s beginning to sound like marketing blurb.

Ditch the feature shopping list. Think customer journeys.

  • Thursday, 19 October, 2006
  • By:

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

  • Monday, 16 October, 2006
  • By:

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.

Chinese whispers in IT projects

  • Tuesday, 10 October, 2006
  • By:

Hello. I’m a developer. I’m going to build your product. I do what the BA tells me.
Hello. I’m a business analyst. I’m going to articulate requirements for the developer. I listen to the product owner.
Hello. I’m the product owner. I’m responsible for what goes in it. I’m going to tell the BA what it should do. I listen to the sales Manager to find out what features the product needs.
Hello. I’m the Sales Manager. I know what features my customer wants, I listen to them.

Hello. I’m Head of Procurement. I’m responsible for selecting the product. I tell the Sales Manager in the product company what we want. I know what we want because I listen to the Division Managers.
Hello. I’m the Division Manager. I want a product that does %%&***£$%£ to drive my sales. Give me a product that does that.

Hello. My name is Sally. I use the product. You know, the thing I really like about it is $%$£$$£^. And here’s a list of what I really hate. Give me a bit of $££%£$”£ and I’d be so much more productive. But noone listens to me.

Hello, I write this blog. I’m an interaction designer. I’ve just sat with Sally for the morning and seen what she’s done. And you know what – we’re getting this wrong. What she really needs is ########. That would really add value.  And it’s is far simpler, quicker and cheaper to deliver than what your guys were proposing.

My life as a BA

  • Monday, 18 September, 2006
  • By:

I recently found myself in the role of “BA” on a project. I’m usually involved in “quick starting” projects; driving out high level requirements, developing project / programme roadmaps and helping clients produce tangible visions of where they want to get to. For me, the story lifecycle ceases at the “as a… / I want to… so that…” It is still a placeholder for a conversation – we’ve not yet started to look at the detail. So It’s been good to drill deeper into the anatomy of a story. and so I found myself with the daunting task of writing “acceptance criteria”.

I’m not really a completer-finisher; I’m more into the big picture, so having to get into test detail has the potential to get painful. But this is where I am grateful to Dan North for his Behaviour Driven Development 101 before commencing the gig, and in particular around testing:

Given…
When…
Then…

Inspired. Suddenly the acceptance criteria are in language that I can understand. It becomes a joy to tease out criteria. And it is easier to say when enough is enough – it is after all about diminishing returns (hey Dan?) The value really shone out when a client was explaining complex rules around how some equity trading functionality would work. It was hard to understand what the requirement was. So I asked him to put himself in the shoes of the developers who will build the functionality. How will they know when they are finished? I scribbled out three columns – given / when / then. He then succinctly articulated the scenarios within this framework. What had been hard for him to explain, and even harder for me to comprehend suddenly became clear. Within a couple of minutes we had the story wrapped up were able to move on to the next story on our pile.

If you give me something, don’t make me work to use it

  • Friday, 15 September, 2006
  • By:

My Nokia N80 came with a bunch of software including Nokia PC suite and Lifeblog. the former is for syncing up the phone with the PC, whilst Lifeblog looks after all the photos I take on the phone. Now you’d of thought that two peices of software on the same CD from the same supplier, packaged with their phone would be compatible with each other. Think again! I’ve got PC suite open and I try to upload photos from the phone using Lifeblog. And I get the below message…

nokia1.gif

I get a message asking me to restart my computer and try again (which won’t rectify the problem because PC suite loads in the system tray). Sorry Nokia. Poor customer experience. You’ve given me a couple of cool peices of software, but haven’t bothered to ensure they are compatible. Or maybe you did but it was a bug that was discovered too late. Now what if they’d been thinking in terms of behaviour driven design:

Given: I have PC suite and Lifeblog open at the same time

When: I choose to upload photos using Lifeblog

Then: the photos will upload and appear in the Timeline view

Or is that too obvious?

Corporate trust in the 2.0 world

  • Monday, 4 September, 2006
  • By:

A successful relationship is built upon communication and trust. That’s obvious in social interactions – when trust is replaced by suspicion and talking is replaced by arguing, a break-up or divorce is inevitable.As an employee I have a relationship with my employer. At ThoughtWorks the relationship is underpinned by communication and trust. ThoughtWorks understands me as an individual with the power of expression. They let you know this in simple (i.e. non-legalese jargon) disclaimer at the bottom of the page on ThoughtBlogs which takes an RSS feed of this page.

Disclaimer: ThoughtWorks embraces the individuality of the people in the organization and hence the opinions expressed in the blogs may contradict each other and also may not represent the opinions of ThoughtWorks.

Working for TW is more about what I can do rather than what I can’t. (And it is a good reason why I love working for them).

Contrast this with many organisations that are more interested in restricting their employees, where interactions are underpinned with suspicion and threatening language. Corporate policies insist that employees sign-up to intrusive and prescriptive “codes of conduct”. The employee is treated as a threat, who will take advantage of anything that is given to them. “Business matters” are everything:

Access to the internet is provided by The Company for business matters only and is subject to the relevant rules governing employee behaviour and is subject to The Company disciplinary procedures, up to and including termination of employment. The company is entitled at any time to examine and/or monitor any usage of any kind on The Company’s premises or using The Company’s equipment. Mess with the Company and The Company will mess with you.

Hardly the language of a successful relationship. Maybe it is time to start challenging this language. With Web 2.0 concepts creeping into corporate life (corporate blogs, Wikis etc) organisations are going to face the dilemma of either maintaining existing prescriptive policies (“thou shalt not…”) or starting to trust their employees, to allow individual expression (“you can… [but]”). The two cannot co-exist. And once the internet codes of conduct are ripped to pieces, maybe innovation can start to flourish. Isn’t it when employees are doing “non-business matters” that the greatest innovations are born?

9 of 13
5678910111213