I’ve been wanting to talk about the transition from corporate life to startup founder (and how balancing the two is often necessary) for a while, and this was a great opportunity to talk about a few of the things I’ve learned over the past 18 months working on Speakr while holding down a demanding job.  The event wasn’t filmed, but here are my slides.

A couple of my slides generated a lot of nodding heads (at least I think they were nodding – it was quite dark). I talked about the gap between thinking about doing something, and actually doing it, using the analogy of The Penny Gap.

Venture Capitalists sometimes complain that entrepreneurs assume an elastic relationship between price and demand (that the line between them on a graph is effectively straight – the higher the price, the lower the  demand). The reality they say is that there is a demand cliff between a free service, and one that charges just a penny, like this:

There seems to be a similar relationship between thinking about ideas and taking action on them, like this:

While we’re fantasising about our idea and the impact it could have on the world – anything seems possible, until we start trying to do something about it. Then it seems a lot harder, and more often than not we let it go. Sometimes though, if the idea is a really good one, we don’t.

That’s where really interesting things can happen.

@anthony__lewis

Like many people who make a living from getting stuff done, problems are an everyday thing: they’re just part of the rich tapestry of projects, and indeed – life. I wrote about problem solving a while ago here and here, but the question made me think more deeply about the different ways to approach problems, and I was pretty happy with what I came up with as an answer, so I thought I’d share a slightly fuller version of it here.

As we work through projects, delivering the building blocks that contribute to a successful programme (as per the figure below), the rate of progress varies, depending on resourcing, focus, constraints, problems and so on. Sometimes problems don’t impact progress for longer than it takes to have a conversation, but others can have a more disruptive impact – taking longer to return progress to the critical path.

1. Validate
In a project team (and even more so in a programme team), there is a variable threshold for uncertainty: one person’s major issue is a line on another’s To Do list. Treating everything that happens unexpectedly as a problem spreads doubt through an organisation, so the first step is to establish whether it merits attention as a problem in its own right (i.e. whether it has the potential to impact key parts of the project), or whether it’s just something that needs to be added to a To Do list.

2. Solve
If the problem is a simple one, then a little thought and a few conversations are often enough. If it’s more involved then I’ll get a few people (3 or 4 seems to be the sweet spot) together and whiteboard potential solutions until we’ve agreed on a solution that;

• will work, and;
• we can explain to the rest of the team, and more importantly the client.

3. Work-around
If we can’t come up with a viable solution, or if constraints (usually time and the associated resource costs) mean that there’s no time to implement a thought-through solution, then we go to the next step – working around the problem.
On well-run projects we can batch most of these together for post-go live resolution. On other projects, they may be ignored and forgotten in time; contributing to a belief amongst people that have to use the systems / processes that a project leaves behind that the term ‘Phase 2’ is a project management joke.

4. Escalate
Successful (or more accurately: ‘successfully perceived’) project management often comes down to deciding when to buffer (if you pass on every problem without resolution, a client can legitimately ask ‘what am I paying you for?’) and when to escalate. These are my tips for escalation:

a)    Provide the background to a problem, to ensure the client is well-briefed. Few project managers will survive the fallout from a client appearing ill-informed about a major issue on their watch;
b)    Articulate the steps you and the team have been through to solve the problem;
c)    Recommend a course of action – ideally the thinking you’ve done will mean that this fits in the context of the project and the wider organisation;
d)    Be prepared for the client rejecting your plan – it pays to have a fall-back position. This is usually when your earlier whiteboarding session proves its value.

Some problems are not resolvable. In these cases it pays to figure out the root cause and make sure that you learn the lessons the project is teaching you.

@anthony__lewis

I’ve read two books recently that made reflect on practicality (and my family), and the role of failure in forming experience. As project managers we often use building analogies, and the books in question: How Buildings Learn, and To Engineer is Human – The Role of Failure in Success use building, as well as engineering case studies in figuring out why things fail, and how to avoid the same things in future.

Building collapses, plane crashes, and bridge failures (especially those that lead to injury or worse) demand rigorous investigation, but in projects where failure is less obvious – like the average software implementation, investigations are sometimes less than rigorous.

Neither book is recent, but the lessons are timeless. In How Buildings Learn, Stewart Brand talks about buildings that succeed (like modest practical buildings that can be adapted to changing uses), and those that have the appearance of success (such as I.M. Pei’s shiny MediaLab building at MIT, which is – according to Brand – restrictive, difficult to maintain, and which prevents the casual exchange of ideas on which great progress depends).

I’m a believer in platforms and frameworks, whether that’s a platform like eBay, Twitter, and so on where users invent new features that are adopted by the platform as they grow, or frameworks like MSP (Managing Successful Programmes – a flexible, practical approach to help practitioners avoid the mistakes of their forebears).

Platforms are more successful over time than prescriptive processes because no matter how thorough the design process, how sound our thinking, we cannot anticipate every way that people will use the systems we build. We cannot design for every edge case and still deliver to time and budget, so we should design for flexibility that can respond to use in the real world. The legendary management thinker Peter Drucker summed it up in 1985 in the seminal Innovation and Entrepreneurship:

A new venture needs to build in systematic practices to remind itself that its product or service is defined by the customer, not the producer. It needs to constantly challenge itself on the utility and value that its products or services contribute to its customers.

I often seem to read that if we’re not making mistakes we’re not learning, and its true that doing new things (even if they’re only new to an individual or organisation) usually involves more mistakes than is comfortable, but if we’re serious about succeeding – however we define success – we can learn the lessons of others’ mistakes, by reading about them, and learning from them.

If you’re interested in learning the lessons of project success (and failure), reading How Buildings Learn, and To Engineer is Human is a good start.

‘When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can oftentimes arrive at some very elegant and simple solutions. Most people just don’t put in the time or energy to get there.’

When I’m working on the interaction design of corporate systems for clients, I’m almost always briefed that the design ‘must be simple’, and I’ve been thinking about what that means.

In the wonderful Simple and Usable, Giles Colborne describes four methods of simplifying, using a TV remote control redesign as an example project:

• Remove – get rid of all unnecessary buttons until the device is stripped back to its essentials
• Organize – arrange the buttons into groups that make more sense
• Hide – hide all but the most important buttons…so that they don’t distract the user
• Displace – create a very simple remote control…and control the rest via a menu on the TV screen

These are steps in the journey towards simplicity, but if they’re used on their own, then they’re only impacting the surface of a design without addressing the fundamental purpose of the interface, or the needs of the user. In his book Simplicity, Edward de Bono makes the distinction between Simple (focusing on the core of a problem) and Simplistic (removing complexity), and to me this beautifully summarises a point that I made much more clumsily a while ago.

A lot of people seem to have a hard time thinking through a problem – it’s easier just to cut and paste solutions we’re familiar with, or take stuff away until we have a solution that looks simple. With the first approach we might be solving a different problem or ‘fighting the last war’, with the second approach; despite its simplicity, we might be obscuring the job to be done. If a user cannot see how to perform their task, they are more likely to abandon or circumvent the process we’ve designed.

The world is complex, as are so are many of the problems that we need to solve, and the key to solving them is applied thought. The Feynman Problem-Solving Algorithm, supposedly coined in jest by another Nobel Prize-winning physicist, Murray Gell-Mann, described legendary physicist Richard Feynman‘s innate problem-solving ability:

1. Write down the problem.
2. Think very hard.
3. Write down the answer.

Gell-Mann was apparently being facetious, but with the addition of a couple more loops, the Feynman Algorithm describes the key steps:

Simplicity is subjective, contextual, and difficult to test – this makes it a poor input variable.
Rigorous thought, and focus on the problem we’re trying to solve will give us a fighting chance of arriving at the most useful solution within the context of the problem.
From the user’s perspective, the most useful solution is often the simplest, and we’ll find that the people who use our designs will say ‘oh, that’s really simple’ – bringing to mind Mark Twain’s quip on the effort it takes to give the appearance of simplicity to the reader:

‘I didn’t have time to write a short letter, so I wrote a long one instead.’

Simplicity isn’t an input of the design process – it’s an outcome of a applied thinking.

@anthony__lewis

There’s an old saying in the ad world, attributed to John Wanamaker: ‘Half the money I spend on advertising is wasted; the trouble is I don’t know which half’.
Designing systems can feel a lot like this – agonising for hours over which features people will find valuable, which part is the core of the product, and more than anything else; ‘What the Users Want’. Des Traynor wrote eloquently about this recently.

Finding out what users (or in a more traditional sense: customers) want fall into two main groups – the first being the hero / genius model, where the designer decides what the public needs and builds it for them, including Thomas Edison, Henry ‘If I asked my customers what they want, they’d say a faster horse’ Ford, and the ubiquitous Steve Jobs. As Freakonomics tells us – any business with a hero / genius model, whether music or sport or drug dealing, is filled with people lower down the pyramid of success struggling to make their mark.

The second model, based on the scientific method has emerged relatively recently in technology, thanks in part to the rise of ‘big data’ and the means to analyse it, and the data-driven approach to web optimisation championed by Lean Startup’s Eric Ries. In this approach, every design variant can be tested with real users (through A/B testing), and the most successful chosen based on hard data. While having some obvious benefits (the ability to quote the data to show that implementing the whim of a senior exec would be disastrous for conversion being one), an over-reliance on data-as-design-aid, can lead to focusing on the wrong things – as the legendary Jared Spool wrote recently.

The answer seems to lie somewhere in between; I wrote a while ago about the differing strengths of people vs systems – the human mind is exceptionally good at connecting disparate thoughts and experiences, and technologies into new ideas – the insight that fuels the creation of new products and services, and drives great businesses.

Systems, and the maturing analytics software market that use them, are incredibly good at analysing the user behavior that shows whether our great idea is any good at all. If we can’t test if an idea is any good, what’s to stop us flitting to the next one when we meet the first real resistance and forging a reputation as an ‘Ideas’ person, or more likely, as a corporate magpie – jumping from one shiny new thing to the next.

However, if we rely on data to make every decision, we’re looking backwards to decide how to go forward , and when the time comes to make the big decision, where the data is inconclusive (or absent) we’ll be terrified of the responsibility.

In business, as in life, there is risk at every turn – most of us do all we can to minimise risk, to understand the context of our decisions, and have the courage of our convictions.

The truth is that if we’re doing something new, we never really *know*. As a once-decent crooner sang; ‘you gotta have faith.’ And data.

In a talk called Inform to Inspire Steph Troeth spoke about the creative process – putting in the work to provide fertile ground for insight to occur, of the importance of resting the mind to generating ideas, and I found that an image of a teapot came into my head.

For the last nine months I’ve been working on a project (which will be public in a month or so) – latterly with a brilliant team of freelancers. The fact that we all have to do other things to pay the bills means that we pick the idea up, sketch / code / figure stuff out, share what we’ve done, talk about it, change it a bit, and put it down again. We’ve done this many times – gradually editing, smoothing, improving, building a working relationship that I treasure, and a shared understanding of the app – taking little steps that looking back over a period of months have resulted in huge strides.

Steph’s talk reminded me of the importance of giving an idea space to take shape, mature, and grow into a ‘thing’, rather than a delicate, ephemeral concept.

It’s like brewing tea: if you rush it to ‘deliver’ the tea as soon as possible, it’s weak, and chances are you’ll be told to make it again.

If you leave the tea to brew too long because you’re afraid that it’s not quite ready, it’ll be stale and the person you made the tea for in the first place has probably gone to the coffee shop.

In their awesome keynote talk at FOWD, the Standardistas talked about James Webb-Young’s ‘five stages’ from his seminal Technique for Producing Ideas:

1. Gathering raw material
2. Mastication (or: ‘let it brew’)
3. Drop everything and walk away
4. Out of nowhere an idea materializes
5. The morning after (is it strong enough to stand up in the light of day)

Every day we discover a new tool or technology to help us build our ideas faster and cheaper, and to distribute them globally for next to nothing – but just because we can, doesn’t mean we should.

Taking time to let an idea develop makes the end result so much more satisfying, like a proper cup of tea after a hard day’s work.

@anthony_lewis

There’s great satisfaction in using a well-designed product, of feeling its heft and texture in your hand, of knowing its story, and sensing its longevity – these are things that age with you.

This winter I helped a web friend chop five hundred or so logs in the snow for his log store – he lent me his splitting axe, and told the story of Granfors Bruks- the company that made it. It was a beautiful simple tool, and it did the one thing it was designed to do very, very well.

Gabriel Brandy, the CEO of Granfors, took over the company when it was bankrupt, when it made axes that no-one wanted to buy – careless workmanship in the forging of the axe head was ground down and covered by paint, the equivalent of ‘chrome’ on a website, to distract from lack of substance. He decided to take the company back to its core, and to build the best axes they could. Now the company has a devoted worldwide following.

As they old saying goes; ‘on the internet, no-one knows you’re a dog’. It’s easy to fire up a WordPress template, or hire a cookie-cutter web development shop and throw up a ‘professional looking’ site, or a boxy form-based system – one that looks and probably reads like thousands of others, but there is a better way.

Curiosity in action - my son at 2 years old, finding out how steering works.

If we start with curiosity  – wanting to understand why things are the way that they are, and how they work, we’ll learn in directions that interest us. We’ll spend time reading, thinking, discussing, drawing and writing – all the time building our understanding of the things that are important to us, and what our place in the world that we’re discovering might be. Over time we develop deep and authentic skill, and we can demonstrate this to others through the work that we do, and the way we respond when things don’t go to plan. It becomes more than chrome, more than presentation or window dressing – it becomes craft.

Steve Jobs used to tell the story of his father’s attitude to craft – taking as much care over the parts of a cabinet or a fence that no-one would see, as those at the front. He insisted on the same attention to perfection inside Apple’s devices, even though most people never see the inside.

If we apply the same level of care to the ideas that we nurture, the copy that we write, the systems that we design, the books we choose to read, the conversations that we have, and the time we spend with others when there’s ‘nothing in it for us’, our work will be like a Granfors axe – authentic, solid, and lasting.

We sometimes hear; ‘the boss doesn’t read anything until the last minute, and then he wants a load of changes.’ Its frustrating, but its also human nature – the busier we are, the thinner our attention is stretched. Unless something stands out from the noise in our inbox, or our reading pile, we won’t give it the attention it might deserve until the last minute.

I was reminded of this truth twice last week: the first time when reviewing legal terms, conditions, and guidance for a web app that’ll be live in a week – the task had been abstract for months: imagining how it might look, and work, based on a ‘powerpoint spec’. Now it’s real, and so is the realisation that what we’re writing will be the focus of a lot of people, not all of whom will want the system to be a success.

For those involved, email response times have dramatically reduced, phone traffic has increased, and the people whose names will be above the shop are actively organising review meetings, wanting to know what’s being done in their name, and manage their exposure. All this is reassuringly predictable – it’d be seriously worrying if no-one cared about the detail a week before go-live, and the frenzy of activity preceding a release is just another stage of a project, where days (and nights) are filled by finding and tying up the loose ends as T minus zero approaches.

The second time I was reminded of signature focus was when writing a talk on solving the problem of business requirements for the Project Challenge Show on the 22^nd March. I’d pitched the talk back in November, and had jotted down a few thoughts; sketching a few ideas for graphics to explain my ideas since. A couple of weeks before the show, I started making a few more notes (constrained a little by the demands of the go-live mentioned above) and putting together a few slides.

The day before the show, the realisation hit that I needed to focus on hammering out a coherent talk that flowed, made sense, and put across the points I wanted to make in an informal, friendly, and useful way. Unlike a lot of people I really enjoy public speaking, but while I don’t mind getting up and talking, I really don’t want to look stupid in front of a lot of people. With the motivating focus of an ultra-close deadline, I finished the slides half an hour before I was due to give the talk, with the flow of ideas fresh in my mind. Judging by the generous follow-up, it went down well.

It’s always sensible to think about things well in advance, and plan them out as much as possible, but the signature focus that deadlines bring are useful, and necessary, and occasionally entertaining.

I’ve been working with a large organisation in the social care sector for the past two years (managing the tech side of an ambitious transformation programme), and in that time I’ve learned a lot about forms.

A typical social care organisation uses forms for everything: a form to record contact, a form to plan support, and a gigantic form to assess people’s social care needs – the Self Assessment Questionnaire, or SAQ. This form can have more than 100 questions, and can run to 15 pages. It’s a beast, and several sections of it can lead to more forms: a financial assessment, a visual impairment assessment, a mental capacity assessment, and so on.

No-one seems to like the SAQ – everyone I’ve spoken to believes that it is far too long, it’s too onerous for social workers, ‘clients’, and admin staff, but despite the efforts and expertise of the design team, reviews of the form lead to only incremental improvements. Why?

One of the fundamental issues with social care forms is that they need to capture unstructured information (conversations between a social worker and someone who has potentially complex social care needs) in a structured format. This can result in a social worker starting an assessment with a blank sheet of paper, making notes as they speak to their client, and shoehorning these notes into the SAQ form when they’re back at base. It’s a reasonable solution – using professional judgment to interpret a conversation into the structured information that is required for an organisation to manage resources and services across a big caseload.

The second major issue is a lack of focus – when a review of forms takes place, everyone can agree that the form needs to be shorter, but with a lack of focus on the core purpose of the form, everyone protects the elements that are useful to them, and those where information ‘might just be needed’. The result is a slightly improved, but still very long form.

The longer and more opaque a form, the less likely people are to complete it in the way an organisation intends – the usual way for organisations to get around this is to enforce compliance through over-use of mandatory fields (the form fields you see with little red asterisks next to them). This is bad.

At BathCamp 29, Joe Leech; cognitive scientist and form design guru at CX Partners, gave a brilliant talk entitled ‘Forms are Boring’ – a whistle-stop tour of the cardinal sins of form design. Foremost amongst these sins being the (over)use of mandatory fields. I had a chat to Joe before his talk about the SAQ, and he listened politely as I expounded my theory of forms – the way a stand-up comedian might listen to someone telling them the Most Hilarious Story Ever™.

My theory is this: that forms should act as funnels. One size cannot fit all, and to try to cover everything that might be required in every scenario is to guarantee frustration for users.

The form funnel should start off with the simplest and most focused form first, which will meet the majority of people’s needs – the ubiquitous 80%, based around the answer to the question; ‘what do most of our users (really) want from us, and how can we best help them to get it?’

The next form (or forms) in the funnel should cater for 80% of the remaining users, and so on, until we’re at the most complex of cases, and that’s where we need our best and most experienced people, and at this stage we’re probably beyond forms.

I’ve hacked together the figure below to illustrate the point – I’ve rounded the figures in stages 3 and 4, but I’m sure you get the idea.

Bad forms (and excessive mandatory fields) are common, but with thought and focus, forms can set our users free.

Faith.

Sometimes we work with people who naturally take responsibility, people who have the ability to imagine their way through problems to practical solutions, people who are prepared to work hard on things that matter and take some heat for not doing the things that don’t – in other words; ‘good’ people.

When we’re working with good people, the dark matter problem is reversed: we’re frequently surprised by the prolific quality of their output, surprised by their creativity that springs from thinking about a problem from a different angle, surprised by the things that they can produce from the foundations we have laid. Robert McKee talks in his Story Seminar about his amazement at how beautiful the words in his scripts could become in the hands of a great actor.

If we have a good idea, and we think about it really hard, and work constantly to refine it; to make it tighter, and more focused. If we have faith in it, and in good people, we can share it with them, and through their thought, and skill, and effort, it can become something amazing.

Sometimes (often) you need to manage tightly – sometimes it pays to have faith.