-
What Customers Want
(or How I Learned to Stop Worrying & Love the Obvious)
(also know as ‘The empty hamburger dilemma’)
Most new products and services fail. This is a depressing reality to swallow, however I am amazed by how few people ask why this happens. Or worse still all the people who have an in-built assumption and acceptance that most new things should fail. This shouldn’t be the case.
Here is a sad graph showing total product failures.
Why all this failure? Read full post
-
Agile training day – another take on visual notetaking
I’ve swithered about posting these notes, given their visual inferiority to Tim’s. But what they lack in beauty, I hope they make up for in utility. I certainly had fun making them. And as someone more adept with a viola in hand than a sketching pen, I’m not too ashamed of my efforts.*
Enjoy.
* Please don’t take that as a cue to harangue me with rubbish viola jokes.
-
Sketchnotes: Agile training day at Made by Many
Over the last couple of weeks we’ve put everyone at Made by Many through a day of Agile Training with Simon Baker and Gus Power from Energized Work.
These guys really are the Penn and Teller of agile software development, and I thought the session was excellent. Most of us here have been trying to work in agile ways for five years or more but this was an opportunity to get better at it by broadening our knowledge and understanding. Another post follows containing some more considered takeaways, but I wanted to share these sketch-notes I made during the day. They petered out towards the end of the day as proceedings became more discursive.
There are 10 pages in total, including a ‘page of evil’ where I tried to capture all of the things that we decided one way or another were EVIL.
See the whole set —-> Read full post
-
A Manifesto for Agile Strategy: oxymoron or innovation?
“You can talk and think about stuff for ages and ages before doing something or other. Why not just do something straight away and learn from that?”
London was basking in unexpected sunshine and Tim Malbon (aka @malbonster) and I were wolfing down some fish and chips in Soho. His off-the-cuff comment stopped me cold – chip halfway to mouth – and in one way or another I have been thinking about it ever since (it was 6 months ago!).
‘Doing over planning‘ might be the simplest way to summarise the Agile philosophy that Made by Many so fervently pursues (a great non-tech articulation of the Agile approach to web apps is Getting Real by 37 Signals).
I was further prompted by Stuart’s excellent recent post exploring some of the differences between “Agile” the philosophy and “agile” the adjective, in which he concludes:
“Two of the most interesting questions for me is how is Agile going to scale beyond a team level? And how well can it be applied to processes outside software development? At Made by Many We have made a lot of ground in Agile interaction design but there is obviously much more to do and tools to create.”
So this is the question that has been haunting me: what role can or does strategy have in an Agile world? Read full post
-
The more you try and practice Agile the less agile you become. And vice versa
This Agile has a capital A. It can also have a lower case a, in which case it is an adjective, to be lean/nimble but that’s not what I’m talking about. Agile with a capital A is a noun, a name used for the philosophy described in the the Manifesto for Agile Software Development and the suite of methodologies primarily used for software development such as SCRUM and Extreme Programming.
Tim’s post on Agile as a ‘Cargo Cult’ highlights a problem in the adoption of Agile, not only for software development but for creative and business processes. Everyone is trying to adapt to a rapid and disruptive world screwing with business models in every category. Organisations are looking to close the gap with nimble digital start-ups who are out-innovating them at a fraction of the cost-base. Agile seems to offer a well-packaged magic ability to compete in a new way.
Unfortunately, a lot of confusion happens between being Agile as an adjective and a noun. Without understanding both, without the philosophy of being nimble and the processes of an Agile methodology, failure is assured.
At it’s best Agile is fluid and rigorous, it can be more controlled and structured than a waterfall project but open to adaption and change. There is a necessary tension between the rigour on one side and it’s resistance to codification on the other so the more you try and practice Agile the less agile you become.
When it comes to adoption lots of people suffer from the McLuhanesque mistake of appropriating the shape of the previous medium as the content for the next (props to Scott McCloud). In this I mean that they try to fit some of the rhetoric of agile around their existing people, culture, process and tools. This normally happens in one of two ways:
-
Tear down this wall! Crowdsourcing comes of age
Hello. I’m Sara and I joined Made by Many last month. My forte is content, so it seems appropriate that my first post should be all about conversation… specifically the two conversations that go with just about every digital project.
Never simple, is it?
The first of these is all about the customers, the people for whom we’re building this product or service. This conversation is pretty user-centric: essentially, what do they need? What are their problems, and how can we help solve — or at least minimise — them?
Then there’s a second conversation — the behind-the-scenes, creative-type stuff about how things actually work. What functionality do we offer? Do our user stories tell the whole story, and does it have a happy ending? What about typeface and layout? And finally, how the hell do we iterate this beast? Read full post
-
“Get Excited And Make Things”
That’s the line that unpacks ‘Planning-ness‘ – an ‘un-planning’ conference held recently in San Francisco.
The idea of “making” things as a way of exploring ideas and developing and articulating strategy is close to our hearts at Made by Many and Planning-ness sounds like a veritable Festival of Awesomeness. I’d love to go next time.
But it was this provocative deck by Jason Oke and Gareth Kay that got us really excited. It’s about the failure of ‘Connections Planning’, the discipline’s historical context, and what it seems to be mutating into – or at least needs to turn into in order to continue mutating.
As someone who is not a planner of any description and doesn’t even work in advertising, I’m not sure I am that entitled to talk about it – although that’s never stopped me before.
It feels like we (the MxM ‘we’) have lots in common with the kind of problems Jason and Gareth are trying to solve, and with the agenda of Planning-ness in general. We come at these problems from a slightly different set of perspectives: Interaction Design, Service Design and Agile Methodologies, but everything is converging – seemingly even our job titles, what we do, and certainly the industries we work in.
Here’s the deck, below. I’ve also picked out some of the highlights (from our MxM perspective). I’m hoping it will provoke a debate inside our company about what we do and how we talk about it – and so, I’m not going to comment too much right now.
I’m also hoping to write something more about the ways we’ve been working experimentally with BBH in very integrated teams on some projects. Mixing what BBH call Engagement Planning up with Interaction Design and Software Development, all within a broadly Agile process, has been really rewarding – and is very relevant to ideas Jason and Gareth set up in Connections Planningness.
-
Pulling Off The Optimal Platform Job
Another week, another blog post on the subject of “why creative advertising folk need to embrace ‘technologists and their geeky ways’” once again ignites vigorous debate.
The post in question is by Joe Mele, VP Client Partner at Razorfish, and received a great many comments and a huge number of re-tweets of the @BBHLabs‘ tweet that contained a link to it. The citizens of Twitter seem to react with a combination of self-loathing and schadenfreudian glee to the disruption that social technologies are wreaking on advertising. It’s a little bit dull and frankly misses the point – and it wasn’t quite (I don’t think) what Joe was saying.
Of course, how advertising responds to the digital challenge is a roasting hot topic. Joe’s blog post quotes a recent article from Ad Age provocatively titled ‘Agencies Need To Start Thinking Like Software Companies’ that talks about hybrid creative techies bringing digital know-how to Madison Avenue. If only it were that easy. It seems overly simplistic to claim that everything will be okay if they hire in some digital savvy, perhaps even ‘developers’ – let them attend client meetings and, you know, even help out with creative ideas and stuff.
Unfortunately, I think it’s a lot more complex than that – and whilst I totally agree with everything Barbarian Group Co-founder Rick Webb, says in the Ad Age article, I’m not convinced he *totally* nails it either:
What they should have been taking away all of this time — and have increasingly begun to — are the concepts of the constant beta and agile development. Marketers need to abandon the time-limited campaign online and start to think of it as a constant application of a rigorous discipline.
Rick’s completely right about needing an agile, adaptive, evolutionary approach, but I’m starting to believe that you need more than that to deliver the kind of long-term living platforms and platform-campaigns – and value – that clients need and agencies must get better at creating. I’m starting to believe you need four things, the first two of which are well-known and increasingly often quoted:
-
Agile measurement
Anjali’s blog post on ‘Measurement versus engagement‘ made me think.
We’ve spent a great deal of effort over the last two years smashing painstakingly integrating Agile thinking into the strategy and design practices, but at the other end – the delivery end of the process – Agile is too often neglected soon after launch.
This shouldn’t be surprising.
It’s difficult, if not impossible, to keep all that innovationism going for extended periods of time. Often, the innovation team within a client organisation moves off onto new projects and hands the service to less risk-friendly teams, where people have KPIs set by line-managers who don’t know about very much about the project and almost certainly have no idea of probably much less understanding of the Customer Value.
Sometimes the fervent adoption of Agile methodologies that happened during the Vision and Service Definition phases turns out to be superficial and temporary. Who doesn’t like Agile when there’s tons of new code and excitement being demonstrated on a daily basis, and when you can get things done with less pain and far more rapidly than you ever did before? It’s definitely more difficult infinitely more challenging to adopt Agile as a culture, over the long term. “Iterative” and “emergent” are best intention ideas that make total sense during the Vision phase – but are VERY difficult to do on an ongoing basis, especially if the culture at large within the client business doesn’t get it, which is a big ask let’s face it!
But occasionally, even on innovation-geared projects, it’s the metrics what kills it.
Typically, there may have been a conversation early on in the project where you were asked to make some guesses about traffic and registered users. You may have been reassured that these would not be treated as promises, and you probably made the point that it’s very risky to make those kind of predictions with an innovative and emergent service like yours, I mean – how could you possibly predict these things, and they’re not the right things to measure anyway..? Whatever. A metrics time-bomb has started ticking.
Agile gets rid of fixed scope/fixed budget which is great – but that means nothing if you replace them with some dumb fixed metrics. So, I’m arguing here not for less measurement or no measurement, but for an Agile approach to measurement – which, obviously, I absolutely understand the need for.
Agile measurement should focus on simplicity and Customer Value. It should make it easier to measure the things that matter to make the service better for its users – to improve the value exchange. Instead of asking what success looks like, ask what value looks like.
It follows then that Agile measurement should measure fewer things. There is a risk – especially with all the new tools and dashboards and diagnostics – of measuring far too much. Measurement is in danger of becoming an end in itself. A smaller set of metrics and diagnostics – “just enough”, in exactly the way as Agile methodologies treat other types of documentation – should help. Even trying to find the “one key metric” that rules them all – and is tied to the economics investment and supported by executive management – is suggested in this awesome paper I found online and have plundered ruthlessly for this blog post. That makes so much sense.
You should also try and measure “outcome” rather than “output”. It’s not about big numbers, it’s about having the biggest impact on Customer Value. A small community of incredibly engaged, high-value customers is much more valuable than 1 million people who registered to win a car. Obviously, you’ll have first needed to have defined upfront what Customer Value actually is – for you, your project and the business sponsoring it. If you’ve been working Agile from the outset, you should have a pretty good idea of your customer/end-user and their needs, and the value exchange that’ll get them returning hopelessly addicted.
Maintaining a living, ongoing dialogue with users will certainly help – and is essential where the one key metric is for example a softie, like brand perception. But you should generally focus on a small set of engagement health indicators: like the number of visits per user per month, dwell time, participation, recommendations to friends, positive buzz across other social networks leading to sustained referrals. I’ll also add receiving offers of help from partners and people wanting to be involved, and good ideas from users – and the holy grail: people start using the site for purposes never envisaged. Remember, EBay realised there was an online market for cars when they found customers selling grown-up cars in the toy section.
Lastly, you should be able to review targets, metrics and diagnostics to optimise your ability to understand Customer Value as the service evolves. Within an emergent, iterative innovation-geared project, you may not even understand the true value and how to achieve it until much later.
What does anyone else think?
Archive for the ‘agile’ Category
You are currently browsing the archives for the agile category.
Our latest tweets
- @chrbutler thanks! glad you like it :) RT @chrbutler @madebymany Your blog is great! It's a never-skip for me. 2 days ago
- @chrbutler mentioned our blog in his post on designing for attention, here: http://bit.ly/aTo8eY 2 days ago
- @apophenia in Technology Review says that people will simply carve out a space for privacy as they think best: http://bit.ly/cbbNdy 2 days ago
- More updates...
Most commented
People
Categories
- advertising (9)
- agile (9)
- Clients (29)
- code (1)
- Conferences (41)
- content (6)
- design (17)
- Games (2)
- Great Stuff (13)
- innovation (25)
- interview (3)
- jobs (1)
- Labs (9)
- Made by Many (142)
- mobile (4)
- New connections (2)
- opinion (50)
- play (1)
- publishing (8)
- Social Web (132)
- technology (2)
- Transmedia (1)
Archives
Sites we like
- Aaron Koblin
- Barbarian Group
- BBH Labs
- Big Spaceship
- Big Spaceship – Think
- Bud Caddell – What Consumes Me
- Creative Applications
- David Armano
- Edward Boches
- Faris Yakob
- Ffffound
- Gareth Kay
- Howard Rheingold
- Iain Tait – Crack Unit
- idsgn
- Manuel Lima
- Mike Arauz
- Neil Perkin – Only Dead Fish
- Noah Brier
- Not For Paper
- Paul Davis – Our illustrator
- TED Blog
- Undercurrent
- We Are Social