{squeaky lean}

The 'Trigger Objective' – The secret of good strategy

strategic planning - trigger objectives

UK cultural reference. http://en.wikipedia.org/wiki/Trigger_(Only_Fools_and_Horses)

Top Rank Objectives can be daunting. So can the strategic planning process required to decide how to go about achieving them.

You know the kind of objective I mean: 'Increase revenue', 'Increase audience'.

They're a bit like: 'Discover meaning of life', 'Deliver world peace'.

Where on earth do you start?!

Just to give you a chance of getting your head around them, you need to break them down into lower level objectives, strategies and tactics.

However, if you read through the conflicting definitions you get from googling 'objectives, strategies, tactics', you'll get a headache.

What we are all actually looking for, are ways of improving our strategic planning process. A good one will deliver us from daunting Top Rank Objectives, safely and easily to what I call 'Trigger Objectives', which aren't daunting at all.

A Trigger Objective is a much lower level objective, set in the reality of the here and now. It relates closely to the knowledge and experience of you and your team, so you can easily list a set of actions or experiments that you think might achieve it.

But the real beauty of a Trigger Objective is that when you achieve it, it sets off a chain of events that sends you on your way to that daunting Top Rank Objective, without you having to spend a moment thinking about it.

Here's how you find Trigger Objectives:

1. Write down your Top Ranking Objective (TRO)

For most profit-making organisations, this is either 'Increase profit', or 'Increase revenue', depending on which stage of development your company is at.

Not exactly life affirming I know.

But life affirming is what your Vision, Values and Mission Statements are for. There's no need to be fancy about your TRO, just be honest and write down what it is.

Now. Get everyone you need to contribute to your TRO together. Or at least a representative from each relevant department. They need to be a part of the debate that comes next.

2. Decide your 2nd rank objectives and pick one

We're still talking high level here. Looking at your P&L might help, as these could be related to your main revenue lines. In my world, if I was doing this for one of our publishing websites like NME.com or GoodtoKnow.co.uk, our 2nd rank objectives might be:

  • Increase display ad revenues
  • Increase sponsorship revenues
  • Increase affiliate revenues

If you stopped here, and asked a team to suggest actions or experiments that would achieve one of these, you would get either blank faces or a cacophony of ideas with no focus. And no idea which ones to start with.

So keep moving. You need to focus on one of the objectives and dig into it further.

Weight them in terms of current value (perhaps based on overall planned revenue contribution) and opportunity for new value (based on which ones you feel have more room for growth).

In my example we'll pick 'Increase display ad revenues'.

3. Decide your 3rd rank objectives and pick one

Thinking through the levers that effect 'Increase display ad revenues', I can list these 3rd rank objectives:

  • Increase display ad inventory (providing more ad space to sell)
  • Increase display ad yield (a higher value per ad sold)

Again, we're still too high, so I'll pick one to dig into further.

Lets say ad yield is holding strong, but we're short of ad inventory. If this were true then choosing would be easy, we'd dig into 'Increase display ad inventory'

4. Decide your 4th rank objectives and pick one

There is really only one metric that effects the amount of inventory we have on a website: page impressions. Some people might include ads per page, but we certainly don't go about adding more ad slots to pages just to increase inventory. So our 4th rank objectives should be levers that effect page impressions:

  • Increase unique visitors
  • Increase visits per unique visitor
  • Increase pages per visit

Right. At about this level – lively debate breaks out.

Suddenly there are people in the room exclaiming that our SEO is woeful so we should work on that to increase Unique Visitors. Someone else is complaining that retention is low and that a membership club of some kind would do wonders to increase our Visits Per Unique Visitor.

This is how you know you're close to Trigger Objectives . Pennies start dropping and people start to jump a step, because we're at a low enough level for people to engage their own knowledge and experience.

Data is still your closest ally though. Use your metrics to settle the debate and pick one objective to focus on. In our example, the data is pointing to Unique Visitors as our search rankings have dropped sharply in the past few months.

5. Decide your Trigger Objective

What can be done to 'Increase Unique Visitors'?

  • Increase offline marketing activity
  • Increase online marketing activity
  • Increase visitors from organic search
  • Increase social referrals
  • Increase month on month visitor retention

From the discussion in step 4, SEO was raised, and search metrics discussed. It's what helped us decide to focus on Unique Visitors in the first place, so lets just pick it:

  • Increase visitors from organic search


Done. You have discovered your Trigger Objective. At Level 5.  

Interestingly, I'd say most Trigger Objectives are found at this level. It's perhaps why Eric Reis' – 5 Why's works so well.

No stopping now though. Time to move onto Tactics.

Your tactics are the actions you're going to take to hit your Trigger Objective. As its a Trigger Objective you won't have any problem coming up with a nice, big healthy list. The team has helped steer you to this objective, so they should be brimming with ideas.

List them and prioritise them.

I can reveal now that at IPC, we recently went through these exact steps on one website and ended up with this exact Trigger Objective. We also prioritised 'Improve page load times' as our priority tactic. And at the time of writing, the entire team, from Publishing Director to Front End Developer, are completely focused on page load times.

'Even the Publishing Director!?' Yes. He was in the room as we travelled from Increase Revenues, the objective he is ultimately responsible for, all the way to Improve page load times. He's been a part of the collective reasoning that linked one to the other. He is buying into the assumption that faster page load times = increased revenues.

And here is the path that links them, in all its glory:

Looking at the diagram above, you can see there's no need for a long winded strategy document. This diagram contains your Top Rank Objective, your Strategy, your Trigger Objective and your Priority Tactic.  Displaying it in a format such as the one above, makes it immediately clear what you are focusing on. Which makes it more valuable.

Also, if you decide to pivot from this strategy, you can see that you don't need to dismiss the entire path. You might instead move up one level and down to a different Trigger Objective. Or you might go up two or three levels, before choosing a different path. You have a mechanism for the team to use to make these decisions without having to start from scratch.

It should be a living model, changing as you discover new levers that effect bubbles in the diagram, or prove existing levers redundant.

For now though: find your Trigger Objective, decide the Priority Tactic, and go build, launch, measure, learn, build, launch, measure, learn…..etc.

Like this?

By Kevin Heery.


Beat the competition. Be a slave to your development team.

In a company that has managers responsible for the success of a product, and developers who produce that product, the company's hierarchy normally places the managers 'above' the developers.

'Above' implies that it is the managers who request things of the development team, and the development team who respond on demand. Not the other way around.

And that, in the main, is how things are.

Thing is, it is this situation that damages the quality of a product and reduces the speed at which it gets to market. 

To fix this, once a manager has handed a project over to the development team, he or she should be answerable to that team, on demand, until the completion of the project. They should expect to be interrogated as and when the team require answers, and should be quick with decisions as and when the team need direction.

Why? Well, a few reasons, but the one I want to talk about here is context switching.

What is Context Switching?
Imagine your mother has asked you to bake a chocolate cake for a party this evening. You've not baked a cake before, but you're pretty excited about it.

  1. You get started, and soon realise you don't know which type of flour to use. You call your mother. She's playing poker and says she'll call back in an hour.
  2. You mow the lawn in the meantime. CONTEXT SWITCH No 1
  3. An hour later, your mother calls and tells you about the flour. Great, back to the cake. CONTEXT SWITCH No 2
  4. You spend 15 minutes going back over what you'd done so far to get yourself back up to speed. Baking and gardening require different mindsets after all.
  5. 15 minutes later you're wondering if it's ok just to use the chocolate egg you got for Easter.
  6. You call your mother again.
  7. She's spending her poker winnings on a spa treatment and can't be disturbed for the afternoon.
  8. You sigh, and decide to go and varnish the garden fence. Not as pressing a task as the cake, but it needs doing, so why not. CONTEXT SWITCH No 3
  9. At about 5pm your mother calls back.
  10. She says you need to get special cooking chocolate.
  11. You violently smash up the Easter chocolate with a rolling-pin. CONTEXT SWITCH No 4
  12. You trudge to the shop and come back with the chocolate. CONTEXT SWITCH No 5
  13. You read the recipe and retrace your steps for a third time. CONTEXT SWITCH No 6
  14. Your excitement about the whole cake thing has diminished substantially and suddenly you're not interested in how it will taste anymore, just about getting it done.
  15. Later that evening as people eat dry chocolate cake, your mother tells you you shouldn't have cooked it so long.
  16. You love your mother, but you spike her coffee with laxatives all the same. CONTEXT SWITCH No 7

What went wrong?

The cake went off track because when you needed more information, your mother wasn't available to provide it, so you had to stop working on it.

Your only choice was to switch to a different task and a different context.

Different contexts require different mindsets, knowledge and skill sets. Putting one set away, taking out another and getting the hang of it again can be exhausting and confusing if you have to keep doing it.

Context switching like this also makes it very difficult to keep tuned-in enough to spot mistakes, or to find those extra improvements that make a product great.

Is overall productivity effected?

Yes, because the context switching itself takes time. People don't move seamlessly from one to the other without losing momentum. Losing momentum by switching often can slow down projects drastically.

So what would have made the cake better?

Your mother answering your questions the moment you needed them answering. That way you could have just got on with it, keeping your momentum along with your excitement and pride in the quality of the cake.

Stop beating yourself up. The bad cake was her fault.

Anyway… back to business now please?

Yeah, sorry. Enough about cake.

As I've said, when 'management' hand the development team a project, they should then be answerable to the development team until the project is finished.

They need to be available to answer questions and to make decisions. Not at the next meeting, but as and when questions need answering and decisions need making.

But 'management' have things to do as well. Aren't you just passing the context switching problem to them?

Yep. And that's how it should be.

What?! Why?!

Because protecting those who produce your product from context switching, by swallowing it yourself, is what good managers do. It's what good management IS.

Good managers tell their team that they can call them or go see them when they need to. If you don't have time for these calls or visits then either:

  • Delegate this authority to someone who will, and forego the right to complain about the end product
  • Acknowledge that if the project isn't important enough for you to make the time, then the team shouldn't be working on it in the first place
  • Make time

Like this?

By Kevin Heery.


Hit objectives quicker through Validated Learning. Here's how.

Validated Learning is another key concept in Eric Reis' Lean Startup book. He talks about how startups can learn from what they've launched already, to influence what they build next.

For bigger companies, installing a validated learning approach is more complicated.

The problem is that a lot of them see Agile like this:

"Yeah, Agile! We do that. We hand the dev team a prioritised list of things to build, and they tell us how much they can get done in 4 weeks.

We draw straws. Whoever picks the short one, goes to see the developers once a day to discuss progress. They do this at a white board with cards and coloured pens. And no-one's allowed to sit down in case they can't get up again.

At the end of the 4 weeks the developers will have built and launched all our stuff. We hand them a new list and they start again. I think we pay them in cake."

Sounds good right?

Actually, there are two things wrong with it:

  1. It assumes that whoever hands the dev team the prioritised list is the rare kind of genius that knows exactly what should be done and in what order. That they need no feedback at all to help them grow your company faster than mere mortals could possibly achieve; and
  2. It assumes that the products are always perfect first time, every time. That you can just launch them and forget them, confident that the world will be enthralled by their sheer magnificence. And without a single tweak required.

Thing is:

  1. They're not that rare kind of genius; and
  2. Products are never right first time

Assuming we're agreed on those two points, we should try to change the way we do things to accommodate them.

So along with our developers, editorial team, sales people and anyone else with a say in what the dev team do, we need to always:

  1. Improve our knowledge of which products and features will delight our audience; and
  2. Check that the products and features we launch are having the desired effect on our audience

The good news is that just by doing number 2, we get number 1 for free!

Validating launched products and features

I'm assuming that your dev team is using an Agile approach to development. If not, at least go and sort that bit out first. I don't care which flavour of Agile they use, just that the basic concepts are being followed.

Done? Good. Your dev team should be proudly standing by a whiteboard that looks like this:

Good for your dev team. Now get everyone else to join in.

Everyone needs to feel responsible for whether or not the products and features being delivered are the right products and features to deliver. And everyone needs to feel responsible for wether or not they are performing as well as they could be.

To achieve this, all you need to do is:

  1. Make sure, as a team, you've agreed your objective along with an immediate KPI to improve. Read objective setting for dummies for more on this
  2. Write the KPI, the current score and a target score on the top of the whiteboard
  3. Add a column to the end of the workflow board entitled 'Validating'

User stories (Agile speak for a feature that needs building) normally finish their journey across an Agile workflow board once they're released to the live environment and no bugs show up. They are considered DONE.

But not when you add a Validating column.

The story would instead move from DONE to VALIDATING, meaning that the team are in the process of measuring and monitoring the story to decide wether it's working in business terms. I.e. If it is positively effecting the chosen KPI.

I recently launched a pilot programme to try this approach at the company I work.

How WE do it

Every two weeks, about 10 people who work on a brand website: publishing, editorial, development, and in some cases even the Managing Director, will stand at the board and discuss the stories in the validated column.

By this time, the product manager will have ensured there is results data against the chosen KPI, and they will have written the relevant numbers under the story card.

As a story's merits are debated, there are three possible outcomes for it, each of which normally trigger an action:

    1. It is proven to be a success and gets to live out its days proudly in the 'Good Idea' envelope at the bottom of the board

      • New similar stories might be generated because of its success.
      • Some further A/B testing might be agreed, to see if its results can be improved even further
      • Related stories in the backlog might be prioritised higher because there is more confidence that they will improve the KPI
    2. It is deemed a failure and is vanquished to the 'Bad Idea' envelope at the bottom of the board

      • The product or feature might rolled back so it can't do any more damage
      • Related cards in the backlog might be removed, ripped up and binned
      • We may learn that it was our approach that was flawed, rather than the idea, and a new story is generated to do it the way it should have been done first time round
    3. It's deemed too early to tell if it is a good or a bad idea

      • We might agree to wait another two weeks to debate again
      • We decide wether or not related stories should be put on hold until this one is validated
As you can see from the pic below, we weren't as harsh as to actually call the envelopes "Good idea" / "Bad Idea", but you get the idea:validated learning envelopes

Once this debate is finished, we go into a meeting room and build a backlog for the next two weeks with all of this data and debate fresh in our minds.

This is Validated Learning.

We've been doing it this way for 3 months and the sense of pace towards a focused goal has increased significantly.

Also, because everyone is motivated by the KPI, there is a natural collective push for Minimum Viable Product. The team now crave fast feedback through metrics. They know they can get it quicker by first validating a less sophisticated version of the planned end product, so they do.

Overall, they are more engaged because they always have a common goal and are regularly measuring themselves against it. As a team.

And suddenly, the trusty workflow board has developed from:

  • a tool used to help a product manager and a dev team work through their backlog of work,
  • to a tool used by the wider business to pinpoint the tactics required to hit the business' objectives.

And its the same £100 white board it was before. Pretty good value if you ask me.

So, in summary:

  1. Pick a KPI
  2. Add a VALIDATING column
  3. Debate the value of things in the Validating column regularly
  4. Take action based on the outcome of these debates

And that's Validated Learning.

Like this?


By Kevin Heery.


Get your wasted time back. Here's how!

Big company culture


"Right. I'm stuck. Before I can move on I need to get the editor, publisher, marketer and sales person to agree if I do it this way or that way. Lets check the diary. Ah, product meeting next Thursday. Only a week away! I'll add this to the agenda. In the meantime, lets start this other thing…After I eat cake"

Startup culture


"Right. I'm stuck. Before I can move on I need to get the editor, publisher, marketer and sales person to agree if I do it this way or that way. [stands up and shouts]. RIGHT YOU LOT – GATHER ROUND.
Ok. I can do it this way or that way. What should I do? [5 minute heated debate]. That way then. Fine. I'll get on with it..After I eat cake"

Now consider that this situation happens a lot.


  • Who gets their product out first?
  • Is speed to market all about how much resource you have?
  • Have you ever considered the average length of time your products just sit waiting, on their journey from idea to reality?
  • Isn't cake where the real money is?

Diagram: First section of a Value Stream Map for a real, award-winning (dontcha know) website

You can click/touch the image to see it better. I think.

Yeah, that's right. A Value Stream Map!

What the %$*@ is one of them then?

In this case, it's a visual representation of everything that needs to happen to a feature on this website to get it from 'Developer picks it up' to 'Live on site, in front of real people'. This  diagram isn't in fact the whole value stream map. It's just the bit I can fit into this post. About a quarter of it!

So first point of note: There is an awful lot of hoops to jump through for a feature on its journey from concept to glorious reality.

On the diagram you will notice a pink line running underneath the steps in the workflow. This is a time line. Numbers below the line are estimates of time it takes to actually carry out an action. Numbers above the line are estimates of time where nothing happens. Waiting time. Wasted time.

Second point of note: There is between 7.5 and 10.5 days of time in this value stream, where no value is being added. Wasted time. And as I said, this is just the first quarter of the whole workflow.

Pretty shocking. Very common.

Lets walk through it:

  1. Developer picks up a story (task)
  2. There's a half day of waiting before they get to talk to 'the business' about it and clarify what needs doing. Not actually that bad.
  3. There's about a half day's worth of discussion and clarification
  4. There's 2-5 days of waiting for a designer to become available
  5. The designer gets their stuff done in a day
  6. There's 5 days of waiting for the business to be available to look at the design
  7. And a day to sign it off
  8. (Assuming the business is happy with the design) There's 2-5 days of development
  9. And then it goes off to testing
  10. ….I'll spare you the rest

4.5 – 7.5 days of doing

7.5 – 10.5 days of waiting

I would suggest that before complaining about resource, this particular team should work on claiming back some wasted time. That way the extra resource will be more effective.

Areas to focus on:

  1. Get a 'Team in a Room' approach in place (see 5 lean principles big companies must relearn – this is no.5)
    The knowledge and authority required to approve things, doesn't seem to be around when it's needed.If the team are using agile, are the right people turning up to standup meetings in the morning? And regardless of that, is there a reason the developer can't just pick up the phone to the right person and ask them to approve things now?Is it in fact that the person with authority has too much to do? Or is it that in reality, this project isn't a priority for them? If the last point is true, then this project is going to be very tough.
  2. Design resource is a bottleneck. What can be done to improve this situation? Can the process be altered so the developer doesn't have to wait for design resource before they start development?
  3. The old assumption, that lack of development resource is the main limiting factor, clearly isn't true in this case. In fact, adding development resource to this team would increase the overall waiting time, more than the doing time.
The good news is, the team now know where to focus to make their delivery process faster and more efficient.
They know where their wasted time is going, so they can do something to get it back.

Further reading?

Try the Poppendiecks' books. Very good.

Wikipedia's Value Stream Mapping Page.

Like this?

By Kevin Heery.


MVP Jenga – What's a Minimum Viable Product and How do I Get one?

Minimum Viable Product - MVP JengaMinimum Viable Product (MVP). What's one of them? How do I identify one for my next launch?

Wel lets imagine you run a news website.

You've measured your customer journey KPIs and identified your next objective:

"Improve first to second visit conversion rate"

You arrived at this objective after seeing good audience acquisition numbers, but disappointing return visits. You dug a bit further and decided it was the new users, rather than returning users, that were the problem.

Nice objective setting. I'm impressed.

You went further. You got your team together, ran a brainstorm and everyone is now very excited about one big idea:

Categorised News Alerts

  • Users sign up via Facebook, Twitter or an internal registration system, which will be built by your own team
  • Users will select from 20 different categories of news
  • And will be automatically alerted via their chosen communication method, as soon as a relevant news story is published

So, you are now about go and tell your team to make it so. They will carry out this instruction smoothly and efficiently and in no time at all, your return visit numbers will be legendary.


It will take your team five times longer than expected, your new visitors will completely ignore this feature and will never return. And it will have been an enormous waste of time.

Sorry. I even annoyed myself slighty there. BUT, lets face it, it's not like the latter situation is rare. It happens all the time, and it's often nobody's fault.

As hard as people try to make things happen EXACTLY as planned, unforseen circumstances and unpredictable audience behaviour can make a mockery of your plan and your wonderful idea.

How do you account for this then?

Let me tell you about MVP Jenga.

What's that you ask?

Well, if I'm honest, I just made it up. But stay with me here.

MVP Jenga

..is a game you play with your product team. If you've read 5 lessons a lean startup must relearn, then you'll know that this product team consists of everyone who might contribute to you achieving your objective. Here's how you play:


Make sure the team know the background of the product idea. Talk through:

– The objective and how you arrived at it
– Your product vision

Beginning the game:

Ask people to suggest simpler versions of the product. A successful suggestion must meet three criteria:

  1. It must be simpler and easier to develop
  2. An audience would recognise it as an improvement to the current available product
  3. It must be a valid test of whether or not the product vision will actually help achieve your objective

The first person who has a suggestion that passes these 3 criteria, gets 1 point, and wins round 1.


Keep going through as many rounds as you can. In round 2 a successful suggestion earns 2 points, in round 3 its 4 points, in round 4 its 8 points, and the scores double like that until no-one can improve on the previous suggestion.

When that happens, the game ends and the team have unearthed a Minimum Viable Product.

The person with the most points is given a 20% pay rise while the person with the least points is escorted from the building.

That last part is optional.

Right, lets imagine your news website team playing MVP Jenga with the product idea: Categorised News Alerts

Round 1:

Tracy, digital marketer, is very excited that there is some kind of game being played at work. She is ready to dive straight in.

"Maybe we can tell if people like the idea of news alerts without them having to sign up to our own system. All my friends use Facebook these days", says Tracy, "And I bet there are hundreds more people on there I don't even know! Maybe that's enough. Maybe it's enough without Twittle even?"

The team let out a collective sigh, but after debating her idea against the three criteria, Bang! Point in the bag for Tracy.

Tracy screams and then taps away on her phone to tell everyone she knows of the monumental event that's just occurred.

Scores: Tracy 1. Everyone else 0.

Round 2:

After just 20 seconds of silence, Phil, the new PHP developer in the team, stops scratching himself and says "As far as I can tell, the complicated bit of this is the automation of the alerts. What if the editorial team just alert people manually when they publish a news story, by logging into Facebook Admin?"

Phil is immediately hit by ice-cold stares from Janet, the editor, and Steve, the staff writer.

Janet thinks fast and says "Phil seems simply to be moving the work from himself to Steve. Steve would be the one who has to do all the extra work. I mean, I wouldn't have the time to help out with that."

Steve's eyes move quickly from Phil to Janet, and then slowly to the floor. "What the..?!" thinks Steve.

The team debate the idea and eventually fall on the side of Phil, based on the expected increased speed to market of his idea.

Even though there are six people in the room, Steve feels very lonely.

Scores: Tracy 1 Phil 2

Round 3:

Quinten, the publisher, has been wondering why we can't just build the original product vision. But all of a sudden he understands. He can see the benefit of having a product in the market much sooner, and at far less cost, giving him feedback on whether this whole news alert idea is actually any good in the first place.

He stands up and shouts "I'VE GOT ONE! Rather than doing this for 20 categories straight away, how about we just do it for sport stories. If that seemed to work we could roll it out for other categories later! And it will make Steve's job much easier until we decide to automate it after all!"

Steve looks up at Quinten thankfully. Quinten pats Steve on the head.

The team debate this idea and SCORE! Quinten comes from nowhere to take the lead with 4 points.

Round 4:

Eddie, the product manager, has been squirming a little, thinking 'I'm the product manager for pity's sake, everyone's wondering why I haven't got any points yet. Come on Eddie, think. THINK!…At least say something. ANYTHING!'

"I know", squeaks Eddie, he doesn't normally squeak, and a few people can't help snigger, "To find out if new visitors might be interested in news alerts at all, why don't we just ask them when they turn up? And get their email address from them.


Once they do it we can tell them the feature is coming soon, but not do any more development unless enough people show interest"

Silence. No Facebook, no Twitter, no registration system, just capturing an email address. No categories, not even any actual alerts! 'It's too simple' thinks Eddie, 'they think I'm an idiot. What have I DONE?!'

Phil, itchy PHP developer, breaks the silence. "Well it's certainly easier from my point of view. Check cookie, present message, take email address. I can just stick it in a text file. Couple of hours work I reckon"

Next, Tracey. "Still looks like extra value. If people are interested in alerts then it should be a nice surprise for them. They won't know we're planning more, so they won't be disappointed"

And finally, Steve. "And isn't it still a valid test too? If plenty of people sign up, then we know they're interested in alerts. If not, then we know they're not. We'll have a good idea of what percentage of new visitors are interested and we can decide wether or not to do any more development once those results are in."

'YESSSSS!!!', thinks Eddie. And everyone is agreed. His idea passes. 8 points.

Scores: Tracy 1, Phil 2, Quinten 4, Eddie 8.

Round 5:

Nothing. Eddie wins this game of MVP Jenga, and this online news site team has identified a Minimum Viable Product – an MVP.

But, what happened to the vision? What about the actual news alerts?

Well, if the MVP shows there is an audience for news alerts, then the team might progress to sending some manual sport alerts out, to see if their 1st to 2nd visit conversion rate actually goes up.

If it does, they might progress to either manual alerts on more categories, or decide it's already successful enough to build in the automation – and save Steve's weekends.

Then they might introduce Facebook Connect, to see if that improves sign up conversion, and then Twitter to see if it improves even further.

And hey presto, they arrive at their original product vision, probably just as quickly, and after having a product live in the market providing business value, for months.

Even if the MVP is successful though, somewhere along their original path, the team will see data about their audience's behaviour that will surprise them and it will steer them onto a different path.

This is a good thing.

They will be driven by real user feedback rather than assumptions. They will find the product people WANT rather than the one the team ASSUME they want.

And their business will be more successful because of it.

Because of MVP Jenga.

Try it.

And let me know if it works!

Like this?

By Kevin Heery.


Objective Setting for Dummies

Every company should have a robust objective setting process that all managers are trained in.

But they don't.

The reason they don't is that once people get to a position in a company where they're first asked to write some objectives, they decide it would be too embarrassing to say "I don't know how. Can someone show me?".

So they set some anyway, and their boss accepts them.

They are a bit surprised by this, but the more they think about it, the more they begin to think "you know what, WHY am I surprised?! I must simply be a natural at this!"

They're not. So thinking this is bad.

Soon, they start to get cocky and begin criticising other people's objectives. They can sometimes be heard trying to explain to people in patronising tones, the difference between 'tactics' and 'strategies' – "that is in fact a tactic, you see, not a strategy, you should listen to me, you see, I am an expert, I write objectives you know" – STOP LISTENING TO THEM! Their lips are moving up and down for the sole reason of letting nonsense fall out of their mouths. You won't get anything useful out of the conversation.

That might sound harsh, and what they are saying might even be technically correct, but for these people it's not about having GOOD objectives, strategies or tactics – it's about persuading people that they know what these things are. They think that's enough.

IT ISN'T! Nowhere near enough. In fact, its dangerous to let someone loose on the objective setting thing if they think this way.

So ignore them until they learn their lesson. And know this – it's because so many people act this way and get away with it, that objective setting doesn't get identified as a skills gap, and nobody thinks there's any need for training.

This has to stop.

So I'm going to kick off and say this:

Until recently, I didn't know how to go through a process that would enable me to identify the right objectives for a project I was responsible for. And I am a senior manager at a major publishing company.

There. I've said it. Join me people!

As my qualified statement implies though, I do know how to do it now. And I'm pretty smug about it if I'm honest.

Turns out it's easy. All you do is…

1. Create a diagram showing the journey of a customer who interacts with your product

Within this, make sure you cover the bits of the journey from where the customer finds out about your product, engages with it, does whatever they need to do for you to make money from it, through to the bit where they put it down and later decide whether or not to pick it up again.

Couple of acronyms to help make sure you cover the bits you need to cover:

ARM (Acquisition, Retention, Monetisation)

See the diagram from Kontagent (Analytics company widely used by social games companies)

  • Acquisition (Think: Cost per Acquisition – CPA)
    How do I get the right audience to turn up for the least amount of money
  • Retention
    How do I persuade them to come back of their own accord, so I don’t have to pay to get them again
  • Monetisation (Think: LifeTime Value – LTV)
    How do I persuade them to buy stuff or do other things that make me money

Your customer journey has to cover all three of these elements. Read more on Nicholas Lovell's blog.

REAL (Reach, Engagement, Activation, Loyalty)

I find this one is good for ad-driven businesses; it covers:

  • Reach
    The fact that people might be aware of your product before they respond and use it.
    Ideally you want to affect this response rate.
  • Engagement
    Once someone does respond, with an ad-driven business model, they need to engage, consuming more content so you drive more ad inventory,  and showing real interest. Interest that advertisers want a share of.
  • Activation
    There's always something you want your audience to do that will make them more valuable. Sign up for something, buy something, refer someone, consume more valuable content (e.g. videos). Activation covers this. You want to activate the customer in terms of making them do the thing(s) that makes them more valuable to you.
  • Loyalty
    Same as Retention in ARM – But if we used 'Retention' here, the acronym would be REAR, rather than REAL. So… Loyalty.
Right. I've taken these, mulled them over and developed a diagram for the user journey on a publishing website. Here it is:

Lets walk it through:

  1. We have to Reach a customer to make them aware of the product.
  2. They need to RESPOND so we actually Acquire them.
  3. Once acquired, we need to ENGAGE as many of them as possible (i.e. make sure they were happy to have turned up in the first place) so we increase our overall level of Engagement, maybe the total number of pages viewed.
  4. As we engage them they are generating ad inventory. For our business to make as much money as possible we need to create enough inventory that our sales team doesn't run out of ad space to sell. This is our AD AVAILABILITY RATE.
  5. At the same time we hope they might buy something from one of our affiliates. We want as high a percentage of people as possible to do this. This percentage is our CONVERSION RATE.
  6. Our AD AVAILABILITY RATE and our CONVERSION RATE drives our Monetisation. Which is, umm… the amount of money we make.
  7. Now we'd like to activate them further. Before they leave we hope some of them sign up and give us some contact details, so we can talk to them without having to wait for them to come back (REGISTRATION RATE) and/or tell a friend about us to give us some free advertising (REFERRAL RATE). If more people do these two things then that improves our Recruitment and Referral numbers.
  8. Finally, once we've got everything we can from them this time round, we hope we've been impressive enough that as many of them as possible remember us and come back again (RETENTION RATE), to improve the overall number of returning customers, which gives us our Retention number.

There. That pretty much covers it. Lets go to step 2.

2. Measure every step of the customer journey

Measure all of it.

And then fall in love with your metrics.

That's what I said, yes. LOVE. METRICS.

Get emotional about them. Lose sleep over them. Keep refreshing your inbox over and over until new ones show up. Feel bitter if your metrics reveal themselves to someone else before you. Lose your temper with them when they say something you don't like, make up with them when you realise it's not their fault (it's yours) and then fall in love with them all over again when they turn to you and say what you've always wanted them to say. – "Your retention rate is up 20%" – oh yes. Such sweet, sweet words!

In the diagram above, we'd need to measure all the white boxes (these will be volume numbers) and all the blue boxes (these will be percentage numbers). Your customer journey diagram has to alternate between volumes and percentages: number, rate, number, rate, number, rate – you get the idea. If it doesn't then you've done it wrong – probably missed something out.

Measuring all this might take a while. Most people already have lots of metrics for the first part of the journey (Acquisition suff) and the middle part (Monetisation stuff), but have much less for the latter part (extra Activation stuff and Retention stuff). So get ALL the measures in place. You DON'T want blind spots! You would be amazed the amount of times a business or project has spent months or even years persevering with an objective that would have clearly been doomed to failure if only they had the right metrics in front of them early enough.

Measured them all? Good. Step 3 then.

3. Identify your strategic gaps

If steps 1 and 2 are done properly, this bit is easy. Look at the percentages for your blue boxes. These are your Key Performance Indicators (KPIs). They tell you how well you are performing at persuading your customers to do the things you need them to in order to make your business work.

Firstly, marvel at the fact that you now have this information. And then at the fact that you didn't have it beforehand.

Next, pat yourself on the back for the KPIs that show you are performing well at something.

Now get over yourself and look at the numbers that tell you the things you're not doing well at. If you want to set proper objectives then finding these numbers are like finding gold. Because once you've found one then you've found a proper objective.

If it's your Engagement Rate, then your objective is to increase your Engagement Rate. If its your Retention Rate then your objective is to improve your Retention Rate (you get the idea).

You may think this suddenly sounds too simple. But its only simple because of the work you've done in steps 1 and 2.

Follow this through and while you are correctly concentrating on the real weak spots of your business, e.g. Retention Rate, your competitors might still be pouring money into the wrong places, e.g. marketing for new audiences that aren't engaging or returning.

They probably don't know they are wasting money, because they probably don't know they have problems with retention. And while they're wasting their time, money and resources on this, you're improving your product to the point where spending marketing money might have become a good idea – which is when you decide Reach and Response Rate have become the weaknesses in your business.

In short. You're being cleverer than them. Enjoy.

Like this?

By Kevin Heery.


Trust vs Control – Why big companies are slower than startups

Big companies, when they started out, consisted of a few people who:

1. Were extremely excited about the vision of the company

2. Were considered by each other as the perfect people for the jobs they were tasked with

3. Cared very much about whether or not the company succeeded

Because of these 3 key facts, they all trusted each other implicitly. And because of this trust, no-one considered putting in processes and controls to make sure they behaved themselves properly. They didn't need them. As far as they were concerned, there was no risk.

The company grew fast. People were hired quickly. And as time went on, the odd mistake was made. None were devastating, but some were bad enough to make someone introduce a process to ensure no-one made the same mistake again.

The bigger the company got, the more there was to lose, and the more processes were introduced to protect itself from that one mistake that might end in disaster.

Protection became more important than innovation.

Control replaced trust.

And there you have it. The velocity of the company in relation to the size of its workforce, had begun its inevitable and never-ending decline.

Why would this slow companies down?

  1. Each new process or control amounts to extra work for a company's staff
  2. This extra work doesn't create ANY incremental value for the company
  3. Even though this extra work is intended to limit mistakes by a company's LESS trustworthy or LESS talented people
  4. It's in fact its MOST trustworthy and MOST talented people who are most affected. It's them who will push on through these controls, when others might give up. So it's them whose time is being used up most by risk reduction rather than value contribution

Now imagine if one of these companies decided only to hire people who fit the 3 criteria at the top of this post. In theory they would decide to add far fewer controls and their velocity per person would not decline.

The speed of a company like this, once it had become large, an enterprise, would be astonishing.

'But what you're suggesting simply isn't realistic! It would take forever to fill vacancies and they'd grow too slowly. And they'd have to pay everyone a fortune!'

Perhaps. But, if you want to be leaner, or if you are a lean team within a big organisation and want to stay that way, then I suggest a different mindset for hiring new staff.

How to recruit so you don't slow down

When you're hiring, the first conversation you should have with any candidate is about your Vision and Values.

Watch and listen closely as you discuss them. By the end of the conversation, can you tell if that person could be put in a room with some strangers, talking them through why your vision is so smart, answering any awkward questions about it eloquently, because they genuinely get it, and believe in it? If so, regardless of whether they have the specific skills for the job you're hiring for or not, you might want to consider hiring them.

If they DO have the skills for the job, hire them immediately.

You can be confident that they will deliver at least 2x the value of someone with similar skills who doesn't have an appreciation of WHY you are asking them to do the work they are doing. If they don't know WHY, and especially if they don't mind not knowing WHY, then I promise you'll be looking at their work in future and wondering WHY on earth they think you should be impressed with it.

Someone who does know WHY, who cares WHY, who can't stand working on something without knowing WHY, someone like that will have a constant conversation with themselves as they work, about wether or not their work will deliver what it truly needs to deliver.

They will end up knowing more about the effect of their work than you do, and they will suggest better ways of delivering the objective that their work is aimed at delivering.

They will end up being critical to your business, so you should pay them well. Not market rate. Top rate.

If, however, you decide you only need 10% of your workforce to display this behaviour, then you will be forced to have them manage the other 90%, just to make the 90% deliver something average.

So now your superstar 10% aren't delivering brilliant stuff any more, they're working too hard turning poor stuff into average stuff. Happy with yourself?

You can even help yourself decide which candidates are worth talking to in the first place by following Nir Eyal's advice and abolishing the usual reference check. Replace it instead with a carefully worded email, that tells referees to reply only if they consider the candidate:

'to be an exceptional employee, in the top 10% of the people you’ve worked with'

..and that..

'if you found their work to be less than exceptional, go ahead and disregard this message and have a great day'.

Nir calls this his "average-need-not-apply method"

And if you think this can only work for startups then read this (pretty long, but worth it) Netflix presentation titled 'Freedom and Responsibility', and you'll see that it seems to be working pretty well for them too.

Essentially, you need the majority of your workforce to display the right values. Companies that follow this path are able to trust their workforce enough not to have to control them and slow them down with extra process. They therefore move quickly towards their vision.

True, they look smug, but forgive them. They can't help it.

Like this?


By Kevin Heery.


Big companies CAN be Lean and Agile!

Welcome to Lean and Large, a site focused on the application of lean agile concepts in large companies.

I don't just mean lean agile IT practices, though that is a major part of it, but also how these concepts can help with strategic planning, business processes, product development, resourcing and even financial planning – within major corporations.

If you're reading this then you may already be aware of, or even an active part of, the Lean Startup movement, a catalyst for which is the superb, eye-opening and mind changing book, The Lean Startup, by Eric Ries.

Lets face it, large organisations have been slow to embrace lean concepts (even though most of them practiced 'lean' before it was a business buzzword – back when they were startups themselves), sometimes applying them to IT and deciding that they've covered it, but blind to the fact that the best of the new startup community are moving many times faster, with more focused strategies, and somehow, with much less resource.

Why? Because they use lean processes right from the analysis of their strategic gaps, through planning, objective setting, team development and on to the delivery of their products and services.

Their whole operations are lean, from top to bottom.

And I'm afraid that's the only way lean practices can make the huge impact it makes for them. It just won't produce the same results if its only practiced in one or two areas of a business.

But, then its too hard isn't it? How do you change the culture of a behemoth? Won't it take many years? And won't it slow us down while we're changing?

No, it's not too hard. We change it a bit at a time, with the easiest bits first (stop with the company wide initiatives already!) It will start making a difference the moment we start changing. And we'll start getting quicker, quickly.

Anyway. That's my kick off post. I hope everyone finds what follows useful – it may not be if it's just me preaching, so I'm relying on input from as many people as possible. Please contribute or get in touch.

Like this?

By Kevin Heery.


What is Lean? 5 Lean Management Principles Big Companies Must Learn

what is lean - 5 lean management principlesWhat is Lean?

A set of principles and practices that help a company or a team create more customer value, faster, with the same resource.

Savvy startups are all reading Eric Reis' 'The Lean Startup' and using the practices he discusses to build and launch their product to real users quickly.  And then to measure their customers' response to the product and learn about how to develop it further to make it more successful.

Moving through this cycle as quickly and as efficiently as possible, so you learn what your customers want and how best to respond, is what gives you competitive advantage. And to move through the cycle quickly, you need to be lean.

These practices are just as important for enterprises who are looking to innovate beyond their core products, so managers who are responsible for innovation, should learn them.

Before we get onto the lean management principles we should all be using, lets just start by saying one important thing:

"Major organisations have already done what all startups dream of doing."

Oh yes Mr Shiny Startup, shying away from the P word ('profit' .. thought I'd better clarify).

All major organisations dreamt up a product or service that they thought people might be interested in, started small and tested it out.

Feedback was good. They optimised and tested some more, listened intently to what their audience thought about it, and at some point, it took off in a big way!

They couldn't keep up with demand. But they responded quickly and grew fast. No one could believe how fast they grew.

They became the young, fresh-faced darlings of their industry. These hugely talented and determined individuals inspired their burgeoning workforce to still bigger and greater things and their company became big. Really big. One of the leaders in its sector.

Brilliant stuff!

So why on earth do so many of these companies, all these years later, have to put up with people questioning their management style, their processes, their siloed structures, even the quality of the food in their canteen (doesn't matter how good your canteen is, people will tell their friends it's terrible – you can't say your canteen's good, don't ask me why, you just can't).

"Actually," I hear you say, "I have a thing or two to say about our company! It IS frustrating when my team and I have to wade through policy, when we have to help other teams with their work while they have no regard for ours, when it's so hard to get time or investment to try out our AMAZING new idea.

But, I had a delicious enchilada in the canteen yesterday and told everyone it was too dry. Why did i DO that?!"

Well, fact is, there was a time when no-one questioned the way your company worked.

Everyone who worked there loved it.

There was an excitement in the air as people felt they were on their way to achieving a shared vision. They understood and believed in this vision. They trusted it. And they trusted each other.

"So what happened to that then?", you ask.

Well, fast growth requires more people. More people, requires some level of bureaucratic structure and a standardisation of roles, responsibilities and processes. 'bureaucratic structure' and 'standardisation', don't sound like phrases that go with 'clear vision' and 'trusting each other' do they.

They don't.

Standardisation is good when you've finished innovating and want some maintenance and protection.

But, taking that away and relying on a shared vision and some trust – well that's what's required when you really want to innovate again.

So – in big companies, you need standardisation for the bits that need protecting, but you need to relax it and go lean for the bits that need innovating.

We're here to talk about being lean and innovating. So here are 5 principles big companies need to relearn:

Lean Management Principle 1: Motivate with a Vision

Your company will have a vision that's written down.

Don't scoff at it (if you are scoffing at it, what are you doing there!). If you think it needs improvement, then improve it. You don't need to get it changed officially.

The point is to ensure you have something you truly believe in, that makes sense and sounds inspiring.

Got one? Now put it on the walls. Talk to everyone about it. Your team, your colleagues, your mum, your mum's bingo friends. Everyone.

Lean Management Principle 2: Set Objectives Objectively

If there is one process you need everyone to know about – it's a robust objective setting process. Less guessing, less copying the shiny thing your competitor is doing, more understanding what your strategic gaps are, and setting objectives to fill them.

Know exactly the journey you want your customers to take from the point they become aware of your product, to the point they become lifelong devotees, buying the product again and again, even if they don't need it anymore, tattooing your logo on their right arm and frightening their friends into acting in the same insane way.

Once you know all those points in a customer's journey where they can decide to behave the way you want them to or not, measure them to see how you're getting on. Make sure you cover how you're doing in terms of customer acquisition, retention and monetisation (and read Nicholas Lovell's posts about this – he introduced me to it!)

Right, once you've done that (and only once you've done that), you can you set some objectives. How can you know what you need to get better at if you don't know what you're not good at?

So set the objectives and then prioritise them. Pick the top three (though one or two would be better).

Now tell everyone again.

(For more on this principle, read Objective Setting for Dummies)

Lean Management Principle 3: Measure Conversion

This bit should be easy because you're now measuring the right things. And you're using the data for identifying gaps and setting objectives. Not for showing off once a month in a report. If you're still not convinced, read Avinash Kaushik's stuff. He'll make you understand that metrics are much more important than you think they are.

The measures specific to your current objectives are your Key Performance Indicators (KPIs), and these should be %s rather than volume numbers. Wherever possible, you're measuring the conversion rate of customers doing whatever it is you need them to do for your revenue model to work.

Once you have your KPIs – Tell everyone.

Lean Management Principle 4: Experimental Product Development

First of all, why are you developing a new product? You work in a company that has had a lot of success with previous products, what's the new one for? Who's it for? Are you sure they want it?

You might well think you're the next Steve Jobs, identifying products you know people want before they even know themselves, without any need for testing early versions out on them.

Um. No. You're not. (But just in case you are  – any chance my wife and I can get a discount for whatever it is you're developing?)

First of all, are you positive that this new product is the only way you can hit that objective and fill that strategic gap.

Let's just make doubly sure you can't hit that objective with the products you already have. Are these products performing as well as they could be? Are you measuring them properly to know you're not missing the fact that some optimisation and some tweaking, or a little bit of reorganising, might not just bring it back to life in terms of a nice healthy growth trajectory?

In the digital world, there are now products (Optimizely and Visual Website Optimiser are good examples) that will let you test dozens of variations of your product on a daily basis, WITHOUT having to bother a single developer.

This is true. These tools are really that good. So why on earth aren't we all obsessively testing, tweaking and optimising our way to much better products without much effort?

Actually, lots of companies ARE doing it. In fact, you know those online companies you admire so much – Amazon, eBay, Facebook? They're doing it. ALL of them. And with great results (see Wired's article on IGN's testing results) – so if you're not, well just get on with it. There is no debate to be had here. You should just get started. Tomorrow!

Dave McClure, who runs the big silicon valley VC, 500 Hats, and was one of the founders of Paypal, believes only 20% of our efforts should be in development, and 80% in optimisation. Watch him yell about this along with some of these other lean topics. He's pretty convincing. And he's done pretty well for himself.

Anyway – back to that shiny new product you have that grand design for. Ok, I'm with you now, let's do it.

20% of it. Sorry, yes. Just 20% of it. And then let's launch it.

I don't mean launching a shoddy product, I mean launching a product with only the absolute core features incorporated into it. Come on now, you know you've thrown everything AND the kitchen sink at it. I know what you were thinking, you want to make sure it works, right? So you didn't want to leave anything out, right?


Be ruthless and pare back the design to its purest form and launch it.

And then run tests with Optimizely and use the results to optimise it.

If you have a hundred days to build a product, launch it on day 20 and spend 80 days optimising it. You'll end up with the product your customers actually want, rather than the one you assume they want. And I don't want to finish this bit on a downer, but if you find out they don't actually want it at all, then you've only invested 20% of the time you would have done otherwise.

(For more on how to identify your Minimum Viable Product, read MVP Jenga – What's a Minimum Viable Product and How Do I Get One?)

Lean Management Principle 5: Team in a Room

The clincher! Get everyone who will contribute to this visionary product of yours, into a room. The same room. At the same time. Together.

I don't mean adding them to some 'collaboration software', I mean face to face. (Collaboration software has a place later, when you have some momentum, but not yet). If you can't be in the same room then set up video conferencing, but make sure everyone can see the whites of each others eyes.

This group of people will be cross-functional. You are breaking down the company's bureaucratic structure and laying it out to fit your new product lifecycle. Everyone who you need to care should be there. Now then – MAKE THEM CARE!

('Team in a Room' will speed up your product development too. Read Get Your Wasted Time Back. Here's How!)

Tell them EVERYTHING! Vision. Objectives. Measures. Product Process. And tell them that right now, right there in that room, is all the knowledge and skill required to get this product from vision to glorious reality. As long as they keep talking, face to face.

And tell them they don't need to write reports for each other any more, not on your project anyway.

Because you know what, they're all going to just trust each other.

Like this?

By Kevin Heery.