Managers and product managers are often frustrated by the apparent lack of care the development team is showing for the needs of the business. The team is forever busy with engineering and design projects (some visible and some well hidden), while business-critical projects are dragging on at a snail’s pace. When a long-awaited product or feature finally launches, it often comes well short of the needs.

It’s tempting to think that the developers — engineers, designers, data engineers, simply don’t care, or lack “right culture”, but that’s actually rarely the case. More often, they’re cut of the planning cycle and are very disconnected from the business. Their goals are always stated in terms of delivering products and features (output), and never in terms of expected business and customer outcomes. Departmental goals and incentives further push developers towards building robust, scalable, elegant software. It is only for them to over-indexes on execution excellence rather than on business success.

Agile Development

Things don’t necessarily get better with agile development. In fact they may get worse. Agile dev did away with project waterfall — Specification → Design → Development → QA, but it didn’t fix the planning waterfall : Strategy→ Roadmap →Project → Execution, which most companies still practice. Management and business folk therefore still live very much in “waterfall world” where big projects are delivered according to well-defined, largely immutable strategies, roadmaps and project plans.

On the flip side, many development teams are now fully immersed in “Agile world” that is all about delivering small increments of working code according to strict rituals. Such teams expect to get a prioritized product backlog and detailed requirements, often in the form of epics and user stories. The bigger context — users, market and business, fades into the background. Historically all agile methods emphasize continuous delivery of value , not code, to users and to the business; all require short feedback loops with users/customers and with stakeholders. However this part of agile development is not practiced as religiously.

For many organizations the solution is product management. Product managers, now also called P roduct Owners, are responsible to bridge the two worlds and “make it all work”. On one side of the dividing gap they’re expected to ship products and features according to the roadmap, not unlike project managers. On the other side, they’re expected to feed an insatiable agile machine, while keeping the engineering team busy and working at full capacity.

Both parts of the PM/PO role are laborious and thankless. Product managers spend a lot of time in stakeholder meetings, planning sessions, reviews, standups, retrospectives, and even more in creating artifacts: OKRs, roadmaps, epics and user stories. It’s hard, time-consuming work that often leaves little room for market research, data analysis, or idea validation, without which it is hard to create products that deliver real impact. Many product managers I speak with know full well that the system is broken and wasteful, but feel powerless to change it.

---

---

Breaking the Walls

In this article I’ll try to explain how switching from top-down waterfall planning to evidence-based product development helps bring management, engineering, product management, design, and stakeholders closer together. To demonstrate, I will reference my own GIST framework .

GIST manages product planning and development in four layers — Goals, Ideas, Steps and Tasks. Simply put, goals define what we wish to achieve, ideas are hypothetical ways to achieve the goals, steps are mini-projects and short activities that develop the idea while validating it, and tasks are the day-to-day activities that implement a step — the things we manage in a sprint backlog or a kanban board. I started using early versions of GIST at Google, and I have since helped numerous companies implement it.

When it comes to tasks, GIST is not trying to introduce a new system. Whatever the team prefers to use is fine — Scrum, Kanban, XP, even just a prioritized task list. GIST is mostly concerned with ensuring that the team is always working towards outcomes and impact — delivering value to the market and capturing value for the company. We will look at the four layers to see how this is done.

Goals is where all parts of the company communicate in a common language, and where the bigger context — the “Why are we doing this” is determined. In general we want to give teams SMART business outcome goals (for example increase onboarding completion rate to 75%), rather than execution, output goals (launch the new onboarding flow). In fact the teams should take part in helping set the goals. Here’s how to do it.

An important first step is to define impact metrics for the organization — the North Star Metric (NSM), that measures how much value we’re delivering to the market, and the the Top-Business KPI that measures how much value we are able to capture back. These metrics communicate what the company considers success and should be top of mind for every employee. Almost everything we do as a company should connect to growing both. To help ensure that we map out submetrics that influence the NSM and the Top KPI — often called outcome metrics and arranged in metrics trees .

We can then assign submetrics to teams — for example onboarding completion rate can be assigned to the growth team. This ensures that all teams are working towards explicit business goals (or towards helping others achieve business goals).

Next we can set quarterly and yearly goals for the most important metrics in the tree. Objectives and Key Results (OKR) usually come in handy here. The teams should take an active part in setting their own goals and as well as proposing missing goals — that are not apparent in the tree such as reducing technical debt or boosting user privacy (This is an important countermeasure to the myopic business fixation that gets so many companies into trouble). The fact that the metrics are all tied in the tree helps with alignment and creation of shared context.

In many organizations choosing product and business ideas is the prerogative of managers and business stakeholders. Product managers may end up being “feature administrators” driving decision-by-committee processes. Evidence-driven companies such as Netflix, AirBnB and Booking.com take a radically different approach. They realize that most ideas fail to show real value, and that they need to test many ideas. They expect and demand product teams to take an active part in idea generation and evaluation. Managers and stakeholders are not out of the picture — they can contribute ideas and have a say, but their ideas are not automatically accepted as the best.

Here are some practices to consider:

• The team is involved in user research both quantitative and qualitative. Observing users and taking part in user interviews is especially important. It is here that the cold metrics take on a human dimension and customer-empathy replaces engineering-only focus.
• Team members are put in direct contact with the business through cross-functional teams (more on this below) and business immersion activities.
• Team members are involved in idea generation through brainstorms, design sprints, hackathons, value mapping and other activities.
• New ideas are triaged regularly by the product manager, often with the help of the design and engineering leads of the team.
• Use of idea banks and a transparent idea ranking system, like ICE (Impact, Confidence, Ease).
• Non-managers have an opportunity to work on their own ideas through 20% time and hackathons.

Steps are short projects in which we both test and develop the idea at the same time. Some steps, for example sending out a survey, require one person working mostly alone for a few days. Other steps, for example a usability study, a smoke test, or an A/B experiment, require a cross-functional team effort for longer duration of time. In Scrum terms a step can span multiple sprints, but can also be shorter than one full sprint.

The Step-Force

The step force (short for step task force) is an ad-hoc, cross-functional squad assembled to plan, and execute a step and to collect and present the results it generated. The step force may include developers, designers, data engineers/analysts, product managers, and in some types of steps, also business owners.

The people in the step force are not focused only on their traditional roles creating requirements and designs, writing code or pushing new software to production. The squad’s larger mission is to make evolve the idea to the point that it can be tested against certain assumptions, risks and hypotheses. This changes what “done” means. For example, the responsibility of an engineer implementing an A/B experiment isn’t just to write code and launch, but to ensure that experiment is running correctly and the experiment is generating sufficient amount of data to enable analysis.

As we start executing it’s easy to get caught up in the tasks and forget about the goals, ideas and steps. To avoid this, I recommend using a GIST board or a similar GIST tracking tool.

The board (physical or digital) shows the part of the GIST plan that the team is working on now:

• Goals on the left — typically these will be key results you set at the beginning of the quarter.
• Ideas in the middle — Put here the ideas you chose for this quarter — the rest should live in an idea bank. If you use ICE, it’s good to write the up-to-date ICE score as well.
• Steps on the right — typically 2–5 steps per idea. It’s good practice to put on the post-it the name of the person that is most responsible to make the step happen — can be a designer, engineer, PM, data analyst, product marketing manager etc.

We want to add to the board also any engineering and design goals we agreed to take on this quarter. It’s important to make these visible and trackable — no hidden work.

I recommend setting up weekly/bi-weekly team status meetings to review and update the board. This is typically a 30-min long meeting that occurs just before the regular weekly/bi-weekly agile planning meeting. The goal is to review the status of the goals, ideas and steps, and to update the board — a great lead-up to the task planning discussion that follows.

Some team members will frown at having at yet another regular meeting, but I can tell you from experience that resistance fades away after the first few meetings. Engineers and designers appreciate the opportunity to rise above the daily tasks and to talk about the bigger picture. My experience has been that this is an important antidote to the obsession with story points and pure-engineering or design initiatives that aren’t connected to any stated goal.

Note: I created a digital, editable template for the GIST board. Grab you free copy here.

Translating Steps into Tasks

Chances are that your team is well-adapt at translating a product backlog into tasks to be placed in a Sprint backlog or Kanban backlog list . Prioritizing the steps creates this exact backlog that the teams require.

Once this is done product managers need to actively reduce the amount of time they invest in “product ownership”. With all the context and clear goals that the team now has this is much easier. You will find that you need to do a lot less hand-holding and guide things at higher level namely the goals, ideas and steps.

Feedback Loops

Information should not flow just one-way between the business and the team. It’s vital to create feedback loops so not catch anyone off guard or without a say. It’s critical to establish trust. Over-communication is imperative — usually the job of the product manager.

All GIST artifacts should be broadly accessible within the company — Goals, Idea banks and GIST board. However don’t assume that managers and business stakeholders will look at them at their own initiative. You must regularly share — over email and in person — what are the goals, are how we doing on them, which ideas are we exploring, what results have we seen, what are the next steps. These are good opportunities to solicit feedback and new ideas, but not top-down decisions — we should decide based on evidence rather than opinions.

Ultimately this type of interaction should cultivate a healthier relationship between all parties — product manager, stakeholders, managers and the team, one that built is built on mutual understanding and trust. Product managers are no longer just roadmap or backlog administrators. They can take their rightful role as customer-experts, leaders of product discovery and helpers in execution.

---

This is a condensed excerpt from my book on GIST. to receive more articles like this and to early-access opportunities to the book. Subscribe to my newsletter