Publishing a changelog is the highest value activity that you’re probably not doing. You might think that keeping a changelog is a boring chore reserved for developers. On the contrary, changelogs are a medium with the potential to transform how we all work. For those of you that already keep changelogs, I’d like to expand your concept of what they can be and do. Changelogs foster product-led growth, multiply the value of work, apply to disciplines outside of engineering, and can be more effective than OKRs in increasing accountability and transparency.

---

What are changelogs?

On the website, Keep a changelog, developer Olivier Lacan covers the basics:

What is a changelog?

A changelog is a file which contains a curated, chronologically ordered list of notable changes for each version of a project.

Why keep a changelog?

To make it easier for users and contributors to see precisely what notable changes have been made between each release (or version) of the project.

Who needs a changelog?

People do. Whether consumers or developers, the end users of software are human beings who care about what’s in the software. When the software changes, people want to know why and how.

---

The hidden powers of external- and internal-facing changelogs

Changelogs are more than a laundry list of software changes. In the post Startups, Write Changelogs, Karri Saarinen, CEO of Linear, writes:

A changelog is a simple way to communicate your progress and culture and celebrate wins. It can be a quick way to align your team to focus on creating user value.

The sneaky power of changelogs is that they multiply the value of both your past and future work. Your external-facing changelog increases the value of your past work. Your internal-facing changelog increases the value of your future work.

External-facing changelogs improve the chance that your advancements will be noticed, leveraged, and appreciated by customers. Changelogs are the ultimate product-led growth device. Instead of creating human touch-points or peripheral content to re-engage your customers, changelogs speak to your customers through the product itself. Changelogs cultivate your customers’ understanding of where your product is today and where it’s going. Understanding feeds loyalty.

To create a great external changelog, you need a great internal changelog. When you sit down to write your customer-facing changelog, you shouldn’t have to start by asking “Wait, what did we ship last week?” — this information should already be at your fingertips in your internal changelog.

Compared to your internal changelog, your external changelog should be curated and centered around customer value. Saarinen advises:

Remember to write about things that are interesting to a human. Don’t include everything you do. Writing about database migrations is not that interesting unless it results in some performance gains or improves the user experience.

Conversely, your internal changelog should be comprehensive and tailored for an audience of your peers. While your customers don’t care about the database migration, your team will care if it led to a bug that made your site go down. And your coworkers will appreciate understanding the business reason behind changes, whether a change succeeded or failed, and what was learned in the process. Imagine if, when you started at a new company, you could read a history of what your predecessors did and why. A thoughtful internal changelog helps your team make better bets in the future.

---

Changelogs are not just for code changes

The terms “changelog” and “release notes” are commonly used interchangeably. I prefer the term “changelog” because of its open-ended simplicity. While “release notes” are constrained to the software release cycle, a log of changes can apply to a diverse range of activities and happenings, beyond code changes.

What types of changes belong on your changelog? Let’s expand changelogs in a few dimensions.

Changelogs can record any change made by your company.

Instead of limiting changelogs to code changes, you can include other activities like marketing campaigns, PR events, social media activity, sales deals, and strategy shifts.

Changelogs can capture changes external to your company.

To paint a full picture of a product’s evolution, the actions made by the company only tell part of the story. External events and environmental shifts belong on your changelog as well. If your company sells consumer products, “Christmas” should be an event on your changelog. The beginning of Covid likely deserves a spot since it potentially had an impact on your operations and customers. If you rely on search engine traffic, a Google algorithm change is a noteworthy event.

Changelogs can consist of words, pictures, and numbers.

Today’s changelogs are textual. Some changelogs, in addition to words, include images, gifs, or demo videos. But if the goal is to capture all forms of change, why not include quantitative measures as well? Metrics can capture changes to your product’s performance like traffic, revenue, net promoter score, page load times, customer acquisition cost, or conversion rates. And metrics can capture changes in your company’s environment, like the employment rate, consumer spending, bitcoin price, or whatever matters in your domain.

Changelogs can tell a story.

Changelogs can be automatically updated with facts as they fold; e.g., “Code X was deployed to production,” “Our company Twitter account tweeted Y,” or “We had Z visitors to our website.” But it’s also valuable for changelogs to tell the story of why changes were made and what happened as a result. Your changelog can be a narrative of your hypotheses, outcomes, and learning. You can’t and shouldn’t explain every change that happens, but the more context, the better.

---

Changelogs multiply the value of work

So what’s the point of recording all of these types of change?

Recording a comprehensive changelog of your company’s actions, circumstances, and outcomes enables you to increase the value of work.

Value takes many forms ranging from social, monetary, technical, or aesthetic. To create value, you must create change by building something, crafting something, or expressing something. You can change bits, atoms, minds, behaviors, systems, or markets to create value. But not all changes are valuable. Many changes are virtually invisible or even harmful. When someone says they will “change the world,” it raises the question “For better or worse?”

Countless metaphors express how making changes, without a notion of value, is wasteful. See “sleep running”, “mistaking motion for progress,” and, in a software context, being a “Feature factory.”

Since work is about making valuable change, it intuitively makes sense that keeping a changelog helps optimize the change you create. Changelogs help you answer:

• Is the effort/impact ratio of your work improving?
• Which of your activities is generating value and which ones aren’t?
• Based on past results, how should you balance investments across different areas like product and marketing?
• If your Northstar metric went up or down, is it something you did or was it an external factor like seasonality, Covid, or a Google algorithm change?

Without accounting for the value of previous work, perception of success is more influenced by politics and bias than actual outcomes.

---

Changelogs eat OKRs

When leaders look to improve alignment, accountability, and transparency in their organization, they look to frameworks like objectives and key results (OKRs). Folks should look to changelogs instead.

OKRs are valuable, but they’re cumbersome to maintain, laden with fantasy, and often contrived.

Imagine if, instead of interrupting work on a regular basis to write OKRs, everyone at your company shared a changelog. When you meet a coworker for the first time, you could read the history of what they’ve been working on and accomplished. It would give you a deep sense of how they operate and what matters to them.

Furthermore, if everyone had a changelog, it would transform how managers judge employee performance. Changelogs make it utterly clear what each person produces and the value that they created.

Changelogs facilitate bottom-up innovation by allowing managers to stay on the cutting edge of what their team is learning.

Of course, changelogs are not a replacement for goals. It’s necessary to periodically take a step back to consider what you’re trying to accomplish. But each of your goals or initiatives should have a changelog. It’s the only way to objectively evaluate progress.

---

Introducing DoubleLoop-powered changelogs

At DoubleLoop, we’re building a system for creating external- and internal-facing changelogs. Here’s what makes our solution unique:

1. Create your internal changelog automatically by integrating your building tools like GitHub, Jira, or Clubhouse.
2. Curate which items appears on your external-facing changelog and add context.
3. Add metrics to show and understand your impact.

Want to see an example? Check out our external-facing changelog!

The Problem

What are the heuristics for separating “important” product changes from minor changes that are essentially background noise? If this question sparks your interest, keep reading.

Everyone who works at a software company must perpetually ask the question: “How did our product change?”

The folks who sell, market, or support the product must understand changes to do their jobs. Since they’re removed from the actual building of the product, this poses a challenge.

Even the people who are hands-on in building the product lose grip of product changes as they unfold. For example, a product manager might know that a change was “ready to go live” in a staging environment, but was it actually deployed yet? They hate having to constantly ask an engineer “Is it live?”, but they have little other choice.

Today, there are two general solutions to solving the problem of product change awareness:

• Machine-driven solutions. Automated notifications of product changes based on code versioning or project management tools.
• Human-driven solutions. Hand-crafted changelogs or communications to stakeholders.

Both types of solutions have downsides.

Automated product change notifications are usually too noisy to be useful. People end up muting the Slack channels with the firehose of GitHub merges or Jira status changes.

Human-driven product updates, conversely, are labor-intensive and fallible. Given the time it takes to write communications, many changes go uncommunicated.

The DoubleLoop Solution

At DoubleLoop, we’ve built a “best of both worlds” solution that hybridizes the machine- and human-driven solutions for communicating product changes. We enable teams to efficiently separate the signal from the noise of automated notifications.

DoubeLoop integrates with code versioning tools (GitHub) and project management tools (Jira or Clubhouse) to generate a source-of-truth of product development activity.

The power is in how we classify events from these systems. In many cases, the classifications come directly from the source tools. For example, we classify a GitHub pull request by repository, branch, and creator. We classify Jira issues by project, epic, type, or requester, etc..

Classifications enable teams to configure filtered communication streams tied to email or Slack. You can configure a “view” in DoubleLoop that sends a message to Slack every time a pull request is merged to master or when a feature is completed for a certain project.

However, DoubleLoop goes beyond importing classifications directly from source tools. To help teams separate the signal from the noise, we apply heuristics to automatically classify the importance of events.

Let’s look at an example of a DoubleLoop heuristic. Events in DoubleLoop can be set to have minor, medium, or major importance. By default, pull requests and code commits are set to have “medium” importance. However, we added a heuristic that automatically downgrades the importance of code merges created by bots (e.g., Dependabot). These commits are things like library upgrades that are minimally interesting to someone who wants to know how the product changed. Teams can filter “minor” events out of their communications streams to reduce noise.

DoubleLoop also has the ability to parse information from commit messages based on naming conventions. For example, if a commit contains the string “feat,” we could automatically classify the change as a feature. If it contains “fix,” we could classify it as a bug fix. These classifications can be used in defining filtered views. For example, someone might want to see only a stream of feature launches without the noise of bug fixes and engineering chores.

Seeking design partners

What other heuristics or parsing rules should we add to DoubleLoop to identify the most relevant product changes?

We’re looking for teams to collaborate with in evolving this part of the DoubleLoop system. The ideal design partner

• ships code at high-velocity,
• feels a strong need to separate the signal from the noise
• is able to install our GitHub, Jira, or Clubhouse integration, and
• is willing to provide us feedback on a regular basis, ideally through a cross-company Slack channel.

---

When I meet aspiring startup founders, I’m struck by how many of them quickly abandon their ideas and pivot to something totally different. Sometimes the pivot is relatively small, like a different type of product for the same persona they were already targeting. Other times the pivot is huge, like switching from B2B infrastructure to building a dating app. One founding team tried 15 startup ideas across diverse domains in 21 months. 

For these nimble folks, it feels like their main goal is to found a successful company, any successful company. While they might have strong values for the type of company they want to create, the subject matter is less important to them. Or maybe they need to explore a bunch of directions to discover what they want to work on.

Not being committed to a specific product vision comes with advantages. It allows you to see things unemotionally. You can test products in different markets until one of them swiftly takes off.

I’m in a different bucket. I founded DoubleLoop not because I wanted to be rich or run a successful company (although I wouldn’t mind). I founded DoubleLoop because I envision a better way for people to build software. To make my vision come true, founding a startup is a means to an end. While my mental model for how to proceed changes frequently, nothing will shake me from what I originally set out to do. It’s my “life’s work.”

---

Ever since I randomly watched Free Solo on an airplane, I’ve had an obsession with mountaineering films. The documentary is about Alex Honnold’s quest to “free solo” the steep face of El Capitan; that is, climb perilous heights without a rope.

In one sense, free solo climbing is the exact opposite of what I choose to do. I like endeavors with massive upside and minimal downside. By launching a startup, I’m expected to fail because most of them do. Failure would be painfully disappointing, but not ruinous. But if I succeed, it will be literally like my dream came true (at least I hope it will be like that). With free solo climbing, in contrast, the downside is extreme. If you make a mistake, you fall to your death or get seriously injured.

Despite the differences, I have one big thing in common with climbers like Alex Honnod: a fixation on a singular goal. Observing an exemplar of the “never give up” attitude makes Free Solo both entertaining and illuminating.

After watching Free Solo, I proceeded to devour a gamut of popular mountaineering movies including Meru, Sherpa, Touching the Void, The Summit, Beyond the Edge, and notably Climbing Blind, the story of a climber whose lack of vision doesn’t stand in his way of tricky ascents.

It’s both a blessing and a curse that I’m rarely capable of consuming media purely for its own pleasure. I watched these films, in part, to plumb the discipline of mountaineering for metaphors to apply to my monomaniacal DoubleLoop quest.

As I had hoped, an interesting distinction popped out between alpine-style and expedition-style mountaineering.

Alpine-style is when you pack the bare minimum supplies needed to go straight up and down the mountain, in one strong, lean, fast push.

With expedition-style mountaineering, the team invests more upfront to maximize the odds of success. They set up several camps on the way to the summit, repeatedly going up and down the mountain to bring supplies to higher camps.

Expedition-style mountaineering connects with my experience building DoubleLoop. Early after conceiving the idea, it became clear that there was no alpine-style route to the summit. I set out to create a world where software builders could learn from their predecessors through vivid historical records of past learnings, successes and failures. People liked the idea and signed up to try it. But after compelling my engineering friend to build a primitive version of the product, few folks were willing to spend the effort to actually build historical records in DoubleLoop.

DoubleLoop was my side project and I wasn’t in a position to quit my day job to do it full time. Given that my first attempt to get customer traction didn’t take off, it was clear that I had a big mountain to climb to make the vision real. But I’ve kept climbing. I still have a long way to go, but every month I get closer to the summit. I’m now full-time on DoubleLoop with talented technical partners, paying customers, and like-minded investors.

When you approach a mountain expedition-style, you don’t ascend with immediate ambitions of the summit. Your first goal is to establish a series of camps incrementally higher up the mountain. These camps are connected with fixed rope lines that make it feasible for the team to repeatedly ascend and descend the mountain. Each camp gets stocked with supplies, food, and oxygen for surviving the high elevation.

With alpine-style climbing, if you don’t reach the summit, you have to head all the way back to bottom. Failed attempts don’t yield a material advantage that make second attempts easier. You might as well go climb a different mountain.

Expedition-style mountaineering, in contrast, affords your team optionality and the possibility of multiple attempts to reach the summit. You can wait at the highest camp for good weather. If a subset of your team comes up short on a run at the summit, they can head safely down the mountain while another group takes a stab. While expedition-style mountaineering is more expensive and time consuming than alpine-style, it increases the odds that some members of your team will achieve the goal.

Expedition-style, applied to startup building, leads you to think about your company iterations differently. Instead of looking for a direct route to product/market fit, you start make moves with the purpose of positioning your future company for success, like setting up well-stocked camps progressively higher on the mountain.

Alpine-style company builders apply lean startup methodology, racing to validate the killer app. In this mindset, building a platform before validated user demand is waste. They want to show that people want an app before building the platform behind it.

Expedition-style startup builders apply fat thinking. They build platforms that can be quickly re-oriented in the form of different apps as the team learns. It’s relatively expensive and time-consuming. It requires raising venture capital to build a platform before you know what customers will pay for.

Expedition-style builders must drive customer adoption of a wedge product before their ultimate vision is realized. While high-altitude climbers need oxygen, product builders need users for (1) attracting investors and (2) product development feedback loops. As Matt Mullenweg said, “Usage is like oxygen for ideas.”

---

In mountaineering, a key variable in deciding between alpine- and expedition-style is how far the mountain is from civilization. Mountains nearer to civilization, like in the Alps or Rocky Mountains, lend themselves to alpine-style. The tallest, most remote mountains require expedition-style, like in the Alaska Range or Himilayas.

In choosing what approach to take for your startup, lean or fat, ask yourself the question, “How far is your idea from civilization?”

In startup terms, “distance from civilization” is “distance from an established market.”

If your startup idea is an incrementally better way to serve robust buyer demand, go for it alpine-style. Quickly discover if you’re right or wrong.

If your startup requires creating a new market or new user behavior, you need the expedition-style approach. You’ll need many attempts to find product/market fit, so you want to set up “camps” progressively high up the mountain to maximize your odds of ultimate success.

For your life’s work, go expedition-style. There’s only one mountain to climb so spend more to get there. If you don’t make the summit, probably no one else will for years to come.

---

Mountaineering, obviously, is more dangerous than startup building. But startup building tops mountaineering in levels of uncertainty and ambiguity. While climbers must manage the possibility of unpredictable storms, founding a startup is like heading for a summit without a topographical map. You can’t tell which destinations will be easy or hard to reach until you start moving.

What I’ve learned building DoubleLoop can be expressed as contour lines on a map. I’m learning the coordinates of the highest points with the most customers. I’m setting up the camps to get there.

Both mountaineers and startup builders are looking for the same thing: the global maximum.

It’s a common practice for art students to critique each other’s work as a means to improve. To conduct a critique, one student shares their creation. Then, the artist’s peers describe, analyze, and interpret what they see and feel. The ensuing discussion covers the holistic impact of the work and the details of how it was constructed through the use of mediums, composition, forms, and colors.

The critique process benefits both the subject and the onlookers. The presenting artist digests the feedback to improve their craft. The critiquers, through articulating their own reactions, become more conscious of how audiences perceive art.

When you’re building products, it’s common to critique an interface design mockup. Designers typically go through many revisions, collecting feedback each time to improve aesthetics, usability, messaging, feasibility, and alignment with brand and product strategy.

It’s also common for engineers to critique each other’s code. For most dev teams, pull requests must be reviewed by peers before code is merged into the main branch. The practice improves code quality, cultivates learning, and distributes knowledge across the team.

But how can we critique the work of product management?

Product management work cannot be reduced to design or code. To help PMs improve, it’s not useful to critique the actual product in its current form. When a PM is hired, they wake up inside a product organism that has been created by many individuals over months or years. Understanding why a product is the way it is today requires a deep historical context. PMs can’t undo previous decisions that limit their options moving forward. They can’t wave a wand to fix the problems that exist today. Every product change takes effort and comes with trade-offs.

Getting product feedback from other PMs can be frustrating. Problems seen by other practitioners are often known issues. For example, it’s easy to critique the function of a grocery delivery app or voice assistant software. But many product problems are hard to fix given technical and business constraints.

Consequently, for product managers to help each other improve, the secret is to critique each other’s iterations, not their products.

In shaping product iterations, PMs navigate questions, like these, that are often invisible to the rest of the organization:

• With this new feature, what is our hypothesis?
• Given two features that I know we need to build, how should we sequence them?
• Should we deploy these changes together or break them up over multiple releases?
• Should we ship a primitive version of this feature or does it need to be polished out the gate?
• Should we launch this feature to all users at once or roll it out gradually?
• Should we user test the design pre-implementation or ship it fast and get feedback post-launch?
• How will we know if this feature was successful or not?
• How should we balance building low-effort front-end improvements with high-effort platform improvements?
• When and how should I analyze the outcome of this change?

To critique how a PM conceptualizes product iterations, you can’t look at each iteration in isolation. The product release cadence and embedded feedback loops tell much of the story.

While it’s tempting to discuss questions like the above in the abstract, I’d like to make it more concrete: at DoubleLoop, we’re organizing guilds of product managers to critique each other’s product iterations.

At each meeting, a product manager will share a series of their previous iterations, including the necessary business context and the results, positive or negative, of those iterations. The group will then discuss those iterations, the underlying decisions, methods, and outcomes. The goal is to help each other improve.

If you are interested in participating in our product iteration critique experiment…

 → SIGNUP HERE.

DoubleLoop is the tool that we’ll use to record and share product iterations, like the PM’s equivalent of a design portfolio or GitHub profile.

In How Adults Build Products, I explored a cognitive difference between adults and babies: adults have “endogenous attention” while babies only have “exogenous attention.” In other words, adults have the capacity to control their own attention. For babies, in contrast, their attention is directed by the external world.

Adults behave like babies in the workplace. Instead of staying focused on their true goals, grownup creators allow themselves to chase squirrels, build shiny objects, over-react to customer feedback, or succumb to political pressures. My thesis is that controlling your own attention is key to achieving good results in product development or any creative endeavor.

Since writing the post, I’ve started scratching the surface of meditation, primarily through listening to the How to Meditate series by Jeff Warren in the Calm app. Learning the basics of meditation has helped me appreciate that controlling one’s own attention is not a capability that adults can take for granted — it’s a lifelong skill to cultivate.

For example, I’m pretty good at staying focused on a task in the face of distractions from the external world, but I have huge room to improve in managing distractions from my own mind. After a few hours of practicing meditation, I’m already a bit better at important things like savoring moments with my kids or nature without obsessing over a work problem that can wait until later. I’m learning how to be present.

There’s fascinating potential to translate the techniques of meditation into a system for maximizing innovation, which is what we’ll explore in the rest of this post.

In Meditation Muscle Groups, Jeff Warren explains four muscle groups that get stronger through practicing meditation:

1. Concentration. The ability to commit to a thing and stay focused on it. When your mind wanders, your concentration muscle brings it back.
2. Clarity. The ability to notice when you’ve been distracted. It’s easy for your mind to wander for seconds or minutes without realizing it. The clarity muscle gives you self-awareness of what your mind is doing so your concentration muscle can bring it back to your intended focus.
3. Equanimity. When you’re concentrating, it’s self-defeating to try too hard to block out distractions. The equanimity muscle helps you maintain a relaxed openness to external stimuli. To concentrate, you must allow yourself to experience sensations and thoughts without flinching or overreacting.
4. Friendliness. The friendliness muscle helps you feel goodwill towards others and yourself. When you do get distracted, it doesn’t help to get mad at yourself.

To continue the line of thought I started in How Adults Build Products, the four muscle groups of meditation provide a guide for how to control your own attention, which is key to creating great things. On the surface, the translation to creative work is easy:

1. Concentration. The ability to commit to a creative goal or path.
2. Clarity. The ability to recognize when work has drifted away from the intended focus.
3. Equanimity. The ability to be open to external feedback on your creation without overreacting.
4. Friendliness. Goodwill towards coworkers, collaborators or users.

Part of what makes meditation powerful is that it helps you build those muscles while sitting still. The foundation is committing to a “home base”; that is, a sensation to fixate your concentration on, like the feeling of breathing in and out. You must use all of the meditation muscle groups to keep your attention on your home base. This might sound arduous, but it’s surprisingly entertaining. By staying vigilant towards your mind wandering, you become more aware of the thoughts that pull you away. You gain fascinating insight into your own mind. Meditation makes it a little easier to “pop out” of unwanted thoughts even when you’re not meditating.

With innovation, however, yo can’t always commit to a home base like you do in meditation. In product development, for example, it’s critical to have a north star or Thielian secret to direct your focus, but external feedback should change what you’re doing. In meditation, external stimulus doesn’t change your home base. When creating something new, in contrast, your foundation is unstable. As I explored in The Threat of Hylomorphic Design Thinking and The Fundamental Tension in Product, there’s a constant tension between bending the world and adapting to it.

But even with an unstable home base, the benefits of applying the muscle groups of meditation to the innovation process is deep. Meditation helps you create more space for creative decisions.

At first, I found the notion that meditation creates more “space” in one’s mind to be counter-intuitive since there’s a fixed amount of room in a skull. But now I get it. Meditation has helped me create more space between myself and the thoughts that were previously crowded up against me. The power dynamic between myself and my thoughts is gradually reversing. Instead of my thoughts choosing me, I can look around my spacious mind and choose what to think next. At least, I can do that more than before.

When you’re building something, feedback from your environment crowds your process like thoughts crowd the brain. Your materials don’t work the way you want, new opportunities emerge, people don’t like what you’re doing, new competition pops up, the economic climate changes, etc.. A weak creator knee-jerk reacts to external change and loses their original vision. An equanimous creator, from the comfort of a spacious interior, feels perturbances and methodically decides how, if at all, to adjust course.

The muscle groups of meditation cultivate autopoiesis (self-creation) in the creative process. When those muscles are weak, the outside world governs your creations more than you do.

Neurofeedback tools are emerging to assist with meditation. Dr. Jeff Tarrant writes in Psychology Today:

By monitoring brainwave activity in specific regions of the brain, we can get a pretty good idea if the person is actually engaged in the meditation or is instead, caught in mind wandering. When the attention is focused, the program plays an audio signal, such as a piece of ambient music, indicating to the person that they are “on track.” This provides direct and nearly immediate feedback to the meditator, allowing them to refine their internal awareness.

The vision of my startup DoubleLoop is to provide a similar feedback mechanism for the innovation process. Through integrations with project management and dev tools, DoubleLoop collects the output of finished work to make it clear when your actions have diverged from your goals. DoubleLoop lets you know when your team’s collective mind has wandered.

Now that I’ve blown your mind with the animated gif, watch this video for an explanation of how it all works.

Ever since I first published the Product Management Triangle in 2014, people have asked for versions they can use for their own purposes.

I finally made this a lot easier! I updated the triangle and made it available as a Keynote template. Click here to download it. Edit the diagram however you want. I’d love to see what you do with it.

And here’s an expanded version that shows things that are both internal and external to your company.

Technology entrepreneurs like to say that they’re “making the world a better place” but they usually have little idea about what will happen if their creations are adopted. They often can’t even draw a clear line from what they’re doing to a better world.

This phenomenon was mocked beautifully in one of my favorite sequences from HBO’s Silicon Valley. In that episode, startup founders make claims like these:

• “We’re making the world a better place through paxos algorithms for consensus protocols.”
• “We’re making the world a better place though software defined data centers for cloud computing.”
• “We’re making the world a better place through canonical data models to communicate between end points.”
• “We’re making the world a better place through scalable, fault tolerant distributed databases with acid transactions.”

The sequence exposes the bullshit nature of many startup visions.

Even when you do have plausible narrative for achieving a big goal, your vision drifts from reality when your tech hits the real world. Your customers will use your product in unforeseen ways. The second- and third-order social impacts are impossible to predict. The creators of online social networks didn’t anticipate Trump.

To make an ambitious vision come true, you must perpetually adjust the path to your vision based on how the world is responding to your tech.

This is relatively easy for small startups. The same people with the vision are the ones doing the front-line work. If something unexpected happens, small startups can adjust plans with minimal communication. That said, many startups will quickly forget their original visions when they see a different path to survival (which can either be good or bad).

For larger companies, maintaining a narrative that connects their vision with reality is much harder. Without self-awareness, a company can start doings lots of things that have nothing to do with their intentions.

To illustrate this point, consider this diagram:

Imagine that each cube represents a unit of engineering work. In aggregate, the cubes are the things your company shipped in a given week.

At a big company, only a small number of people are able to understand the contents of each particular cube. Their trail of cryptic code commit notifications does little to explain the work.

To help “manage” all the work being done, companies install project management tools and practices. Each blue box in the diagram represents a set of engineering work captured in the form of issues, stories, bugs, or features.

Project management tools make the engineering work more intelligible to the people working on each project. But just because something is represented in project management software doesn’t mean it maps to a company goal. Project management software, alone, helps you be a better feature factory, but it doesn’t keep you in sync with your vision.

I’m building Double-Loop to help companies achieve, as the top part of the diagram says, complete alignment across strategy, project management, and engineering.

My vision with Double-Loop is to capture every unit of engineering work that your company produces through integrations with tools like GitHub. Each unit of engineering is like a transaction your company makes with the world. And, like transactions in the financial sense, they should be accounted for and reconciled with your company goals. You should know how much you’re “spending” on each goal and the return on investment.

With Double-Loop, as new engineering work is deployed, you’re prompted to map it to your company goals and capture the results achieved after launch. When something doesn’t reconcile easily, it means either your goals need to shift or the work needs to cease.

Today, most companies don’t know how much of their output maps or doesn’t map to their goals. When a company’s work is invisible to the folks steering the ship, it means they’ve created a monster with potential to wreak havoc on the world around them.

 

Babies are born with exogenous attention.  This means that the external world dictates what they pay attention to. A baby could be playing with the best toy ever, but when another toy drops next to them, their attention uncontrollably shifts to the new shiny object. In The Philosophical Baby, Alison Gopnik says that babies can “become captivated by interesting things that they don’t care for, like an unusually bright light or loud noise. They cry and fuss but seem unable to look away, like adults watching a horror movie.”

Gopnik explains that as children grow older, they develop endogenous attention, the ability to control their own attention. They become able to keep their focus on a ball even if a gorilla walks into the room. Or they can choose to give up the beloved ball, if they are persuaded through bribery, threat, or some other measure.

Maintaining endogenous attention is critical in all challenging jobs. A pilot must know where to focus their attention even if a loud alarm is going off in the cock pit. In bounded domains, there is a clear set of rules for where to focus. A pilot is trained where to look for potential danger.

But in unbounded domains where there is no rule book, learning how to control your own attention is an endeavor in itself. When your playing field has no clear parameters and the future is ripe with surprises, the allure of responding reactively to your environment is especially strong.

Kids make cognitive development look easy. Adults, when navigating unbounded domains, must work hard to develop the brain functions they take for granted in other aspects of their life.

Many of companies behave more like children than adults. They chase shiny objects and squirrels instead of staying focused on creating differentiated value. Maintaining your company’s ability to control its own attention, I believe, is a chief meta-responsibility of product management. And the obstacles in doing so are insidious.

Here are some ways PMs can manage the attention of their organization.

1. Resist shiny objects and squirrels.

Building differentiated value requires relentlessly iterating towards a product that fits customer, business, and technical parameters.  It’s a long grind, and often takes longer than people think.

When company leaders get bored waiting for actual progress, making a shiny object or chasing a squirrel is an endorphin rush and might reduce pressure in the short term.

A shiny object is a feature or prototype that excites executives or investors, but doesn’t deliver actual value. As a PM, I like to make shiny objects to inspire the company around a direction I feel the company should go, even knowing that the shiny object itself is problematic in its form. But if a PM makes shiny objects to gain political points without a larger purpose, they are enabling the baby-like distractibility of their executive team.

Companies must be able to quickly pivot their attention when the situation demands it. However, you’re “chasing a squirrel” when you reach for an opportunity that does not build off your core competency, like signing a big partnership that forces your to create one-off custom work.

If you’re lucky, you’ll miss catching the squirrel. If you do catch it, it will fragment your focus and muddle your position in the marketplace.

2. Manage the tension between changing the world and adapting to the world.

Steering your company clear of obvious distractions is the first step to maintaining endogenous attention, but it gets more nuanced from here.

For good reason, companies aspire to be “customer-driven.” Adapting your product based on user feedback is critical. In this sense, having your attention impacted by your external environment is necessary.

But customer behavior and market dynamics are not immutable. Great products change user behavior and create new markets. By over-reacting to external feedback, you end up building a faster horse instead of a car, as they say.

Product-driven companies listen to market signal, process it, and then build things beyond the imagination of their customers. The key is to process the external input, filter it, and make a bet that reflects comprehensive situational awareness. This is how you can reorganize the world around your product.

3. Earn the confidence to place your own bets.

As I described in The Product Management Triangle, product managers sit at the intersection between business, technology, and customers. Consequently,  PMs can apply “full-triangle” thinking to optimally drive their product forward. Thus, PMs, or other folks with a full understanding of their company, should sit in the drivers seat crafting initiatives.

Yet, a PM’s orientation is shaped by input from their cross-functional partners. PMs rely on their teammates and stakeholders to understand customer, market, and technical conditions.

The easy way for product managers to gain the confidence of their peers is to do what they ask for. PMs often build roadmaps that diplomatically mirror the product requests of their stakeholders.

But stakeholders are less qualified to make product decisions than the PM, or at least it should be that way. Each stakeholder may know more than the PM about a facet of the business, but they know less about how the full puzzle comes together. To build impactful products, product teams must call their own shots.

Consequently, a PM needs to earn confidence, not just in their responsiveness to the needs of their organization, but in their ability to make the best bets. Just as you should build stuff beyond the imagination of your customers, you should transcend the imagination of your stakeholders.

I created Double-Loop, in part, to help PMs earn the confidence of their organization. PMs use Double-Loop to share the narrative of their iteration process. PMs are scholars of how the world reacts to product changes, and Double-Loop expresses that. When stakeholders can follow the process of building a continually improving product, they viscerally feel the expertise of the people driving it. This makes stakeholders less likely to prescribe how the product should change. It gives the product team the freedom to experiment at the cutting edge of their knowledge; that is, operate like an adult with full control of their own attention.

My first guest post on Ribbonfarm explores how the experience of navigating a maze mirrors the creative process.

The essay introduces the new Maze Structure booklet, a series of mazes of increasing conceptual complexity. Here are the front and back cover.