The Lifecycle of Goals: Research, Discover, Deliver, Monitor

Product companies tend to manage the lifecycle of projects (AKA ideas) — from the moment the project/initiative is approved until it is shipped. But in a reality where most ideas fail to create value, it is far more important to manage the lifecycle of goals (what we’re attempting to achieve)— from the moment the goal is defined until it is completed. Organizations that effectively work through the goal lifecycle have a massive competitive advantage: they are able to steer themselves towards business and user outcomes rather than “place bets” on specific ideas. 

The lifecycle of a goal is composed of these phases: 

  • Research — Doing exploratory research to understand the context, map out the underlying opportunities and challenges, and uncover ideas
  • Discover — Evaluating and testing ideas and determining with sufficient confidence which ones will positively affect the goal
  • Deliver — Developing and deploying the ideas that were shown to work
  • Monitor — Observing the outcomes generated by the launched ideas and sometimes taking corrective action.

Goal Lifecycle in Practice

Let’s look at an example:

In this example a company selling a productivity suite to medium-large organizations is facing a security problem: in recent quarters customers were repeatedly hit by security incidents and privacy leaks while using the company’s products. While the vulnerabilities are usually detected in advance, it takes a long time to develop solutions and deploy them, and consequently many customers are left unprotected. So this year the company leaders set a goal to enhance the levels of customer security and privacy with a key outcome of having all customers continuously protected from all known threats. 

The goal is assigned to the security team and starts with a 3-week Research phase. The team interviews security officers in customer companies, conducts postmortems, reviews what competitors are doing, and evaluates available 3rd-party and open-source solutions. The research phase yields 9 ideas that show good potential to contribute to the goal. 

In the Discovery phase the team evaluates each idea up close and attempts to validate its effectiveness and feasibility using validation techniques like customer interviews, technical investigations, proofs of concept, usability studies, and dogfooding (testing internally in the company). The discovery phase takes 7 weeks to complete. Most ideas are shown to be less effective or feasible than first imagined, but 3 ideas prove, with medium/high confidence, to create positive impacts on the goal. 

Whenever the team discovers a validated idea it immediately starts implementing it (while continuing to discover others until it has enough ideas to work on). The Delivery phase is about developing a production-ready solution and launching it. It takes a total of 3.5 months to implement and deploy all 3 ideas. 

However due to roll-out delays there’s a lag between the launch of each idea and it taking full effect. The team monitors each idea it deploys and tracks the metrics. In one case, an idea is rolled back, fixed, and relaunched. 

It takes a little over two months from the launch of the first-completed idea, until the goal is achieved (in practice 96% of customers are fully protected; the last 4% are special cases that will require custom solutions, but company management is satisfied with this result and calls the goal Done). Overall, the goal took 6 months to complete, which is about 1 month longer than planned. 

Working Towards Interim Outcomes

Many teams struggle to commit to outcome goals because of these reasons:

  • The outcomes often occur too far into the future and cannot be achieved in one quarter 
  • The team doesn’t have a good sense of what’s achievable and by when
  • The team doesn’t know how to achieve the goal, or even if it’s possible 

When using the goal lifecycle, the team can work towards shorter-term Research, Discovery, and Delivery outcomes that are much more tangible, and yet contributing to the goal. In the example above, the outcomes of the Research phase were lists of the top security issues, relevant technologies, and 9 potential ideas. The outcomes of the Discovery phase were 3 validated ideas that collectively stand to achieve the entire goal. These interim outcomes are measurable and can be placed as key results in the team’s OKRs. 

The outcome of the third phase, Delivery is having the top ideas built and deployed — an output goal — however, at this point the team can simply put the final outcome “All customers are 100% protected” as the key result in its OKRs. 

Not a Waterfall

As always, we should be extremely cautious when depicting product development as a linear, sequential process: 

  • There are no clear cutoff points from one phase to the next. Sometimes we’ll do the research before the goal is set. We may start discovery on some ideas while still conturing with research, and we may switch to delivery on an idea while still discovering others.  
  • It’s (sometimes) two-way — It’s normal that during Discovery we run into some unanswered questions and go back to do more research. We may even want to update the goal based on what we learned. Still, the aim is to make forward-motion and not get stuck, hence it’s good to timebox Research and Discovery.
  • It’s not a handoff between different groups/disciplines — Sure, some companies have separate innovation/incubation teams to handle the Explore and Discover phases, but it’s perfectly normal (and perhaps more productive) for one or more teams to take the goal from inception to completion. Note that the number of people involved will grow from Research to Discover and will peak during the Deliver phase, only to decline sharply during the Monitor phase. 
  • Sometimes we start in the middle — Sometimes we start with an idea that may even be partially implemented, then go upstream and ask “what goals can we achieve with this?”, “What are the underlying opportunities/challenges this idea addresses?” and “What other ideas are there?” This solution-looking-for-a-problem approach is far more risky, but it can yield profound products. For example Apple developed the modern multitouch interface years before it knew what to do with it. Tiny Speck developed an internal communication tool that it later launched as Slack. The key point is to not move forward with delivery before showing that the idea contributes to a meaningful goal. 

Putting Goals Into a Roadmap

We can definitely plot the lifecycle of a goal on a timeline, creating essentially an Outcomes-Based Roadmap. This allows the company to track progress towards the goal, even when it’s too early to see change in the end outcomes. (Note that I added the “Monitor” phase that is not included in the linked article). 


In my workshops we practice implementing evidence-guided development and empowered teams hands-on.

Secure your ticket for the next public workshop or contact me to organize an in-house workshop or keynote for your team. 


Getting Real on Achieving Goals

The technique I’ve shown you in this article isn’t rocket science, but I found it helps tackle two very common challenges:

  1. Teams don’t know how to work towards outcomes — I talked to this one above
  2. Managers underplay or misunderstand the importance of research and discovery 

Both are acute problems, but #2 is often harder to fix because of the obsession with execution and delivery that many companies are inflicted with. This model, along with the many other techniques I cover in Evidence-Guided, help you visualize the alternative to your managers and clearly explain why an evidence-guided approach (that starts with research and discovery) is far more effective in terms of time-to-outcome, resource utilization, and business and user results, not to mention internal culture and cooperation. Give it a go and see how it works for you.

Join my newsletter to get articles like this 
plus exclusive eBooks and templates

Share with a friend or colleague