Originally posted at Cultivate

Are you frustrated by a culture that hasn't caught up with the digital world?

Do you feel like you're building the wrong thing? New features fail to engage and delight customers?

Are you fighting against a culture of inertia? Trying to sell processes to people who don't understand the business value? Are you in a project that's become too big to fail?

This blog post is a few tried and tested techniques, I've found useful to help get projects on track and everyone on the same page.

1. Understand the 'Why'.

Nothing exists in a vacuum. It's vital we understand the goal. Products need a purpose, both at a project and functionality level. What are you trying to achieve and what business value it will bring? This may not be a quantitative value, it could be as fluffy as more customer happiness.

Innovation games are a great way to get at the why, and work well in workshops with a broad spread of stakeholders. These games often surface misunderstandings, leading to discussion and consensus.

Here are a few examples I've games found valuable in this context:

Pragmatic Personas

Pragmatic Personas are a quick, easy way for you and your team to think about who your users might be and what they might want or need from your product. They're non-research backed and draw on the knowledge in your team to get you started quickly. This makes them ideal for identifying who you might want to talk to in you customer development phase. During your customer development or user research activities, you can compare your assumed personas against really behavior and then revise your personas to better reflect your learnings.

The Elevator Pitch

Using the below format, working in pairs, define the elevator pitch for your product.

  For: (User Type)
  Who: (Need to be fullfilled, or job to be done)
  The: (Name of your product)
  Is a: (Description of the product)
  That: (USP of product)
  Unlike: (Competitors or existing product)
  Our Product: (Improvement over current state)

Design The Product Box

What differentiates your product? People buy benefits, not features. Imagine your product was competing for attention on a shelf full of similar products, design a box to get users to buy your product over the others.

2. Focus on outcomes not features.

We work at an amazing time, in an industry full of smart people who want to do great work. Technology has come far enough that we can create incredible solutions to complex problems.

We don't need to have the answers any more, we need to know how to ask the questions. If you can ask for an outcome not a feature, you'll have a happier team, and a better product.

Gojko Adzic's Impact Mapping technique is a favourite of mine for getting stakeholders talking about outcomes not features.

The idea is to start with Why (as discussed above, you can use the assets generated to feed into this activity as reference)

Why?

This is the goal and ideally should be expressed as a SMART goal (Specific, Measurable, Action-oriented, Realistic and Timely)

Goals should present the problem to be solved, not the solution. This is doubly valuable when working with non-technical stakeholders, as it levels the field and de-risks contribution.

Who?

This part of your impact map is about actors. Try to be specific, avoid terms like 'users'. The more specific you can be the better, so if you can list specific users, great. If not, decrease the granularity through personas to role/job title or finally group/department.

Not all 'actors' are equally relevant. To prioritise, you want to consider how central they are to the project. Alistair Cockburn advises looking for three types of actors:

• Primary actors, whose goals are fulfilled, for example players of a gaming system
• Secondary actors, who provide services, for example the fraud prevention team
• Off-stage actors, who have an interest in the behaviours, but are not directly benefiting or providing a service, for example regulators or senior decision-makers

How?

Here we're looking for Jobs to be done, not solutions to the problem. It's also good to try to show how the job is improved – e.g. 'Print twice as many t-shirts per hour' rather than 'Print more t-shirts'

What?

What can we do, as a team, to support the required impacts?

This is where your 'scope' is, options, features you could build, or activities you could undertake to move you towards your goal. Try to keep out of detail here, early on as this the area that contains the most assumptions. Pick a route (the shortest, or most likely to succeed) and run a lean test. If it succeeds, great, carry on. If it fails you can have options! Revisit the map and try the next most likely path.

3. Make your metrics actionable.

Great metrics should be actionable and drive changes. The question you should be asking is 'What will you do differently based on your results?'

One of my takeaways from the Lean Analytics book was 'One Metric That Matters'. This doesn't mean you won't track anything else, but it does mean you know what the one metric really driving your business is.

The book breaks down metrics based on what phase your business is in (Empathy, Stickiness, Virality, Revenue and Scale), and also by what kind of business you're in, to help you figure out what metric might be appropriate.

If you haven't read it already, it's a great book. You should read it.

4. Don't forget the past (Check-in regularly).

Those who cannot remember the past are condemned to repeat it - George Santayana

It's easy to create lots of learning, capture it, file it somewhere and forget about it. Not deliberately, not maliciously, not lazily – just we're busy doing, time moves on and we forget we have these items we can refer back to when we tell our stories.

Keep referring back to your learnings. Some assets we might check back in with:

• Inception Learnings
• Project Pre-mortem
• Storymap
• Customer Development notes
• Vision statements
• Your customers

Another great way to remind yourself to check-in is to create an area that all these documents can remain visible, public, discoverable and importantly, questionable.

5. Defer Decisions.

In Estimation is Evil Ron Jeffries says - at the very beginning, we know less about our project than we’ll ever know again. This is the worst possible moment to be making firm decisions about what we 'require.' This really resonated with me, especially in combination with the Real Options thinking of Chris Matts.

• Options have value
• Options Expire
• Never commit early unless you know why

6. Hunt the value.

Behind all of the previous techniques, is simple but important principle - keep questioning the value of your choices and your assumptions. Question them deliberately and frequently.

Are your goals still correct? Are they delivering the right value? What could you do better? Are you learning the right things?

Seek out better ways of delivering, and ruthlessly cut things that aren't actively helping you progress.

7. Seek forgiveness not permission.

If you feel you should do something, do it.

In many organisations if you ask, you'll likely be told no. It's a default position, no-one's assessed it. If you just do it, you can prove the approach's value, and if you have to, apologise later.

I find this powerful in archaic organisations that aren't easily convinced to change.

The one caveat - think through any legal/ethical issues before you dive in!

Let me know how this worked for you.

If you try these suggestions out, I'd love to hear how you get on. I hope it's awesome, if it is great! If not, I'd love to talk about why. Tweet or email.