• Automatically binds standard hotkeys for common operations on Mac and Windows
• Supports image drag & drop, uploading images from desktop and taking photos with mobile cameras
• Allows a custom built toolbar, no magic markup generators, enabling the web site to use all the goodness of Bootstrap, FortAwesome and so on…
• Does not force any styling – it’s all up to you
• Uses standard browser features, no magic non-standard code, toolbar and keyboard configurable to execute any supported browser command
• Does not create a separate frame, backup text areas etc – instead keeps it simple and runs everything inline in a DIV
• (Optionally) cleans up trailing whitespace and empty divs and spans

(click on the image to download a larger version, feel free to use it in your slides, presentations etc).

The sweet-spot for all the techniques we discussed seems to be enabling these practices, and creating a self-reinforcing loop of better customer understanding and collaboration.

Understand your customer

At the core of delivering software that makes an impact is understanding the customers/stakeholders/users. Before someone blames me for stating the obvious, this isn’t just understanding their needs or desires. In What Customers Want, a book about “Outcome-Driven innovation”, Antony Ulwick warns against focusing too much on what customers are asking for, and instead advises understanding deeply what kind of jobs they want to perform and then offering innovative solutions for improving that work. All the techniques we discussed support a better understanding of users’ work and assumptions.

So to get the most out of all those techniques, leverage this aspect, and use them to understand customers’ assumptions, the work they are trying to perform and the impacts that you want to create as much as you can.

Be comfortable with ambiguity

A common thread for the whole day, as well as one of the key principles that made the final list, was to focus software delivery more on impacts and outcomes than on software features. That means that the actual software that will be delivered is not going to be precisely defined ever – we will keep trying things out until the impacts are there, and we’ll stop when they are achieved. Also, as we’re planning to learn through delivery, we can’t be certain what impacts on users’ work we’ll need to get to the outcome. With such a level of uncertainty and ambiguity about scope, there is not much point in fixing the plans or spending time planning too much. At the same time, there needs to be a good level of transparency, visibility and understanding of the delivery work and plans for everyone to coordinate (and for the clients not to panic). A common thread in all the techniques we discussed is providing a dynamic big-picture view, to prevent a stream-of-consciousness of user stories that don’t achieve anything big and make business people run for the hills.

So to get the most out of all those techniques, leverage this aspect, and make the organisation comfortable with not committing on software features, instead of focusing on making impacts. Provide a clear big picture view connecting all deliverables to business outcomes, show how they help or hinder that, and use those things to monitor and report progress.

Co-create

Another common thread, linking the techniques we discussed with Design Thinking was facilitating a close collaboration between customers/users/stakeholders and delivery teams to create solutions together. Someone (sorry, forgot who) gave a fantastic example of their organisation where they paired up a technical architect and a product person through the entire hierarchy to make decisions together.

So, to get the most out of all those techniques, engage cross-functional groups, involve customers and delivery experts, and use their shared wisdom of crowds to come up with a good delivery plan.

Learn fast

The fourth common factor for many of the techniques we discussed was that they facilitate organisational learning from delivery, establishing a clear and deliberate feedback loop from the outcomes and impacts of deliverables. In “Impact Mapping”, I wrote about this as a third weel that spins business milestone iterations.

So, to get the most out of all those techniques, focus on learning fast. This is closely related to the third principle we extracted, Teams should decide what to do next based on immediate and direct feedback from the use of their work. The more direct and immediate the feedback, the faster we can learn.

Make an impact

Organisations should focus on delivering outcomes and impacts rather than features was another key principle we set out, and by understanding customer needs, engaging them to help design solutions and learning about what worked, we can focus on making big impacts with our work, not just shipping a stream of consciousness of user stories. Many the techniques we discussed facilitate this. They help us define clear business objectives and create a roadmap that drives towards those business goals.

So to get the most out of all those techniques, don’t use them just to map out features – instead show impacts and outcomes and use those things to guide delivery.

Make it visible

By making assumptions, objectives, impacts and scope visible, those tools allow delivery teams and business users/customers to get a better shared understanding and alignment. This includes the impacts we plan to produce, impacts produced already, roadmaps, plans to learn and learnings so far. Visualisation is a common thread in many techniques we discussed, and it seems to also be a key enabling factor for a shared big picture view.

The visual aspect, as David Sibbett suggested in Visual Meetings, seems to add a lot of IQ to everyone in the room.

So to get the most out of all these tools and ideas, make sure the conclusions are visible.

Where next?

For more on this, see what Henrik Kniberg and Karl Scotland thought about it. Also, we created a Google+ Community to hold all the photos and links and there is plenty of good stuff there already.

If this topic sounds interesting, come to my Product Owner Survival Camp in May in London. Book before March 1st with promo code blog to get a £100 discount.

Note that we’ll only accept maps that:

• are created on MindMup.com
• are shared on Twitter with a hashtag #bookfriday between 11AM UK time Friday 15 February 2013 and 11AM UK time Saturday 16 February
• are sensible mind maps (dummy maps, default content or maps that don’t describe books will not be accepted)
• are not copies of other people’s maps

The winners will be notified by a direct message (DM) on Twitter tomorrow at 12 Noon UK time. ( follow @mindmup if you’re not doing it already, so we can send you a DM).

My brain is still buzzing with all the great stuff I’ve heard and expect many more blog posts in the following weeks. For now, here is a quick summary of the conclusions:

Great results happen when:

• People know why they are doing their work
• Organisations focus on delivering outcomes and impacts rather than features
• Teams decide what to do next based on immediate and direct feedback from the use of their work
• Everyone cares

In no particular order, I’d like to thank very much Mary Poppendieck, Gabrielle Benefield, Tom Poppendieck, Gordon Weir, Henrik Kniberg, Jeff Patton, Ingrid Domingues, Karl Scotland, Russ Miles, Christian Hassa, Dulce Goncalves, Aaron Sanders, Shadi Almviken, Chris Matts, Olaf Lewitz and Matthias Edinger for helping define such a crisp message.

To make sure this isn’t too meta or abstract, here is my view of what those things mean:

People know why they are doing their work

A huge problem for many organisations out there is that the big picture is often not communicated to people in the front line. Different stakeholders have different objectives and those are rarely communicated, coordinated or prioritised. Software requirements and scoping models communicate what needs to be done without providing the context, which makes it incredibly difficult for people working on delivery day-to-day to make good decisions on what should or shouldn’t be in scope. It makes it also impossible to decide when the outcomes have been achieved and if they’ve been achieved at all. This creates a disconnect between delivery that measures success in rolling out user stories or satisfying requirements, and customers that measure success by business outcomes.

In addition to communicating scope, organisations should focus on communicating clearly the business reasons behind scope and deliverables (hint: this isn’t the “So that…” part of the user story, but much higher and holistic goals of the organisation). We believe that this will allow people to make much better day to day decisions and improve customer collaboration. Also, by focusing on communicating why something is needed, we create alignment between different business stakeholders and help everyone see the big picture.

Organisations focus on delivering outcomes and impacts rather than features

The measure of success, for many teams out there, is rolling out software features to production. This is when they declare victory. Teams measure and manage things like time, velocity, story points, effort. Those things are inputs and outputs, but not really relevant from a customer or business perspective unless they are too expensive. Consider a car drive. We can measure petrol (input, user stories, estimates), miles per hour (output, velocity) or miles travelled (output, user stories delivered). Those things are good to know that the machine is running OK, but they don’t tell us anything about being close to the actual objective. If we spend too much petrol or drive too slow, we know that something is wrong. Similarly, velocity and story points can tell us that. But the fact that I’ve spent half of my petrol tank and crossed 200 miles doesn’t necessarily mean that I’m any closer to my destination. I could be in Germany instead of France because I drove in the wrong direction. This is where a car GPS comes in, and shows us distance to destination.

We believe that by focusing more on measuring and managing impacts on users and business outcomes, the equivalent of distance to destination, instead of focusing mostly on inputs and outputs of the process, teams can significantly improve delivery, reduce waste, and ensure that the expected business outcomes were achieved. This also provides a framework for delivering outcomes faster, cheaper and differently than originally envisioned, which allows organisations to fully benefit from learning through iterative delivery.

Teams decide what to do next based on immediate and direct feedback from the use of their work

Many smart people have already said that organisations should incorporate learning from delivery into their plans to get the most out of an iterative delivery process. The problem we commonly see is that the feedback loop either does not reach directly to the end users, or that it is too slow or indirect. By ensuring that the feedback loop includes actual use of the deliverables, and finding ways to make it direct and immediate, organisations can leverage iterative delivery much better. This should guide the decision what to do next, driven by outcomes and impacts instead of a shopping list of features. Given a good steer in the direction of expected impacts and outcomes, the team should be able to decide itself how to solve the next problem, and incorporate the learning. Organisations that push feature requests to teams end up getting people who aren’t technical experts to specify solutions, create a bottleneck for communication through product owners who work on a level of information that is too low and fail to get the most out of their delivery potential.

Everyone cares

Several people pointed out that the big difference between opensource projects and the rest of IT is that in opensource everyone cares deeply about the products. Given a big picture view and a good set of expectations from a business perspective, if the front-line delivery people care about the result of their work, the outcomes and impacts caused by that, then they will be able to make good decisions.

For more on this, see what Henrik Kniberg and Karl Scotland thought about it. Also, we created a Google+ Community to hold all the photos and links and I expect other participants to upload their notes and pictures soon, so that would be a good page to periodically check if this is interesting.

After a fantastically inspiring discussion on all the trouble the misunderstanding of the role of product owners causes, I also got inspired to run a full-day Product Owner Survival Camp in May in London. Book before March 1st with promo code blog to get a £100 discount.