Goals, goals, goals

So let’s start with a bit of an introduction.

After 10 years of learning about software delivery and actually delivering IT products, I’ve confirmed for myself that I really like to create things. Whether it’s a quirky side project or a core system for a large organization, creating applications always triggers a combination of analysis, creativity and a lot of learning. However, it’s not just the creation I have enjoyed. The process that guides the creation and sharing thoughts about different approaches within that process started to interest me along the way. Designing and delivering apps at both medium-sized organizations and varying departments of large enterprises (ERM, NCOI, NS, Philips, Rabobank, Vodafone) in different countries gave some interesting insights into when things work, and when they don’t.

It’s time to write down some of the things I have observed and more importantly, some perspectives that those observations gave me. Many times, I’ve come home from a day of work with an urge to share the day’s lessons. A particular approach led to a successful outcome that I had not seen before or, on the other side of the spectrum, not thinking about proper next steps hampered progress. Some questions that I have asked myself and got asked by others include

• “That was a great design sprint! Now what?”
• “So this product owner says the end-users can’t grasp his vision yet. How can I still involve these users in the design?”
• “Every book and self-help article tells me to release often and ‘fail fast’, but should I really convince my client of this?”
• “These people seem to know what they want, why would I challenge their goals for this project?”

With this blog series, I aim to go beyond the methods that are described abundantly. Design sprints, lean startups and agile sprints, they offer organisations great ideas but are not always as straight-forward as the articles and books that describe them make them out to be. I’ll dive into applying these methods and into the why behind them. The stories will probably be most insightful for readers with basic knowledge of concepts like agile and design thinking, but might provide enough background for people new to the field. My experience is based on reading and creating software for companies that are not in software development themselves; it might or might not be different from experiences at the big tech companies.

In the end, I hope to get to the principles that help you and me deliver great applications. Great applications that aren’t built just for the sake of having an application, but that are the best way to fulfil a need or opportunity.

So what are we waiting for, let’s get started!

Goals, goals, goals

It’s the first step in Google Venture’s design sprint and the start of applying Lean Startup, setting a goal. The idea of ‘starting with the end in mind’ makes sense, it’s the number one step that prevents you from solving the wrong problem. While it’s easy to come up with some goal and most organizations have thought about it, it’s worth diving a bit deeper into its nuances. The goal is one of the most crucial elements in creating the right solution and — less obvious — bringing important stakeholders together.

The one-sentence approach

As the book Sprint explains, a design sprint starts with the definition of a one-sentence goal. This sentence should be specific enough to provide guidance, but generic enough to find out the actual reason why you’re here. It thus lies somewhere between ‘we need to make more money’ and ‘we need three screens with tables’. When asking an organization for the goal of an app development project, the answer is usually too specific instead of too generic. Finding the background of this specific goal is related to the Five whys technique in which people are encouraged to dig a bit deeper to find the actual cause of a problem.

Applying the why-technique (let’s forget the number of whys) is very relevant when building software, since the initially defined goal is more often than not ‘to have an app that can do this and that’. This starting point can be iterated upon in two parts:

1. We need to get rid of having the need for an app in the goal sentence
2. We need to remove feature-level details from the sentence

An example

Let’s go through this with an example: “We need a mobile app that brings the organization’s news to its employees”. Getting rid of its first part is quite easy and turns it into “We need to bring the organization’s news to its employees”. Notice how we ignored the part that defined the ‘mobile’ need. The context and modality of what you will create are assumptions that should not be addressed in the goal, but later.

Onto the second bit. Asking why you need to bring the organization’s news to the employees is the start of improvement. It might seem like an open door and it might raise some eyebrows, but there’s usually nuance to be found. A first answer could be that the employees need to be informed, which should both lead to a second why and challenging this assumption. The challenge is needed because an organizational news app is usually not only to inform employees. Often, it’s also to engage people and to create a bit of a community feeling. Getting more clearance on the why will lead to a better idea for the what. Informing employees could be done by pushing some C-level defined messages or giving people the ability to find what they consider interesting. Asking why employees need to be informed can give this insight. Do they need to perform their tasks in a more compliant way, does the leadership team want to flatten the organization?

You get the idea. An example of a resulting sentence that you might be happy with after some iteration is “We need our employees to work more efficiently by knowing what’s happening in the rest of the organization”. Be aware that it’s not the task of a workshop facilitator to define the goal. Rather than giving your own opinion, asking the right questions and repeating the participants’ input will help people to formulate the correct sentence.

The goal should not only give guidance to the direction of the rest of the project, but also build the common ground of your audience and give them a feeling of ownership. In my opinion, this is the real value of pushing for one specific sentence; a discussion about one word can show a different perspective on the project goals from different stakeholders.

Alternative approaches

The one-sentence approach is not the only and not always the best approach. In a workshop with low attendance or only one person with a vision for the project, the bringing-together-effect is minimal. In these cases, one of the following focuses could be more important:

• The long haul. When a project needs a quick result, but will be continuously improvement in the future, it’s good to ask for goals on different time frames. Where do people want to be 6 weeks, 6 months and 6 years from now? This gives a good sense of priorities.
• The experiment. In some cases, it might be very difficult to get to one goal. If this is not a matter of asking better questions but caused by an immature vision, the workshop can be used to prioritize different parts of a goal. When this ambiguity exists, it’s useful to write down the different aspects of the goal, and bring those aspects back in workshop phases like the ‘key questions’ or prioritization of ‘how might we?’ questions.
• Different perspectives. This is more of an addition than an alternative. When stakeholders have different perspectives it’s even more important to get to a shared goal. However, understanding their individual success indicators for the project will help you in getting people with various roles happy. After defining the sentence, you could give people 5 minutes to write down their individual ‘key success indicators’.

To conclude, Tl;dr

This hopefully gives some extra ideas and insights for defining the goal of your application development project. In short:

• Defining the goal is one of the most crucial parts, if not the most crucial part of developing an application.
• Co-creating this goal with various stakeholders will lead to the best common goal and build long-term support for your product.
• The approach for getting to this goal depends on the situation that you’re in. While the one-sentence approach of the book Sprint is great and has beneficial side-effects, tailored projects often require a tailored approach.