Your team’s Slack account has many of the same psychic qualities as a physical office. Some conversations take place “out the open,” in public channels. Others happen “behind closed doors,” in private channels or DMs.

In an office, rampant closed-door sessions, filled with complaints about folks not in the room, breed a culture of distrust and alienation. The same toxic cycle plays out in Slack when grievances are aired privately, out of view from the implicated party.

When closed-door Slack sessions get negative, the impact is more insidious than in an office. In real life, if two people walk into a room and close the door, you know that it’s happening. In Slack, you don’t know about private conversations when you’re not included. Consequently, a suspicion that people are talking behind your back can escalate into paranoia.

As a manager, I love to use Slack to talk to my team. It is especially handy for remote teams and open layout office spaces where private conversations are harder to come by. One-on-one interactions are critical for building deeper connections with coworkers, and Slack facilitates this.

Sometimes one member of my remote team complains to me about another member via Slack DM. And that’s expected and ok. It helps to talk through problems before going directly to the person involved.

But I’ve realized that conversations like this should be rerouted as quickly as possible to a Slack conversation that includes all the people involved. It’s better to talk through the dispute together, without me as a proxy. Sometimes I include another team member in the multi-person DM to serve as a buffer. This makes the interaction feel less like a confrontation. I’ve found this to be an efficient way to get to solutions while keeping the trust level high.

It’s usually best for hard conversations to take place in person. But when this isn’t possible, the same principle applies to Slack.








Analytics tools are limited by the fact that they don’t include (1) a visual history of the apps we’re developing and (2) a record of the team intentions behind launches.

Analytics tools are useful for understanding how the live version of an app is performing. If you wonder how many people are clicking a button, you can see the number of clicks and easily interpret the results.

But analytics tools are not good at painting a detailed picture of how previous versions of the app performed. If you look back at the behavior of your users a year ago according to your analytics, it can be difficult to interpret the recorded actions that are no longer possible in the app. A year ago, clicks on “right nav menu” may have been a common action. This doesn’t carry much meaning if your site hasn’t had a right nav during your tenure at the company.

The inability to visualize previous versions of your app limits the value of old usage data, and this is a missed opportunity.

Let’s say your company sets a goal to increase video streams per user. Your website has had videos for a couple years, but the company has never intentionally tried to increase streams.  In your analytics, you see that the number of video streams elevated on your homepage 14 months ago and then dropped down two months later, before you joined. The company has redesigned the homepage twice since then. The previous product manager added some annotations about the redesigns, but you can’t see what changed or why.

Wouldn’t it be great if you could see, directly in your analytics tool, the version of the site that existed when the video streams spiked? You could incorporate aspects of the old design into your new design for testing. Because you can’t see it, it could take several iterations to discover a version as successful as the previous one, if you ever find it.

Analytics tools also do little to prevent you from retrying failed ideas from the past.

Let’s say you’re trying to increase the conversion rate on your checkout page. Working for a company that’s been around for a while, you’re clearly not the first person with this goal. Wouldn’t it be great if you could browse all the previous attempts to see what was tried and why? A tool like Optimizely would provide some history of experiments, but it’s not designed to expose learning in a form that can be plumbed for future inspiration.

I’m writing this post to convey a future iteration of my project, Double-Loop. The current version of Double-Loop provides part of the puzzle: it enables teams to efficiently record their history of launches and learning. Combining analytics with Double-Loop will open new possibilities of mining value from past analytics.

Here’s an early mockup, developed with my designer friend Dennis Crothers, of how this might look:

Screen Shot 2018-01-11 at 9.58.22 PM.png

While analytics integration isn’t live yet, get a head start building your Double-Loop launch timeline! I believe you’ll find value in co-authoring your company history with teammates. Future team members will love you for it.

My side project, Double-Loop, is an app and Slack bot for recording and sharing the story of your build-measure learn loops.

While anyone can try it (click the above link), I’m looking specifically to test and craft Double-Loop with a small number of post product-market fit companies. If you’re interested, fill out the below form. Selected participants will play a key role shaping the future functionality of Double-Loop.

impossiblecubeStarting with The Product Management Triangle, I’ve argued that a chief responsibility of product managers is to release the tension surrounding a product. In the PM triangle article, I focused on business model tensions and tensions between teams. But since then, I’ve explored an additional four types of product tension.  This post takes a zoomed out view which also serves as a guide to much of my writing over the last three years.

1. Tensions inherent in the business model

Every product has some degree of tension arising from its business model. Since people would rather not pay for things, UX and monetization are fundamentally at odds. The tension is most inflamed in advertising-based business models where the company makes money by making the user experience worse in adding more ads to the page.

PMs live at the conflict line between UX and monetization and must find ways to manage the tension. For example, native ads mitigate biz model tension by meeting monetization goals while minimizing UX damage. An increasing number of SaaS enterprise companies, like Slack, are charging on a per active user basis. While customers would prefer “free,” this minimizes the tension by ensuring that customers only pay in proportion to the value they receive.

For more, see The Product Management Triangle.

2. Tensions between a product and its environment

Launching a new product is like injecting a foreign object into a stable environment. Sometimes the intrusion is embraced while other times its rejected.

PMs must balance two ways of thinking. On the one hand, companies aspire to “change the world” or “dent the universe” with their product. On the other hand, they must adapt their product according to customer feedback and market signal.

The tension between bending the world versus bending to the world is one of my favorite product management dilemmas.

For more, see The Fundamental Tension in Product.

3. Tensions between predictable and unpredictable game plans

Building a product requires navigating an unpredictable future. Yet the people who fund and resource products often want to see clearly defined development roadmaps and predictable budgets.

We’ve seen the software development world drift from waterfall to agile ways of operating. Waterfall methodology puts up a false facade of certainty regarding the path forward. Agile allows teams to iteratively adapt a product based on incremental learning and external response, but legibility is sacrificed. Stakeholders have trouble planning around a product with an unclear future shape and cost structure.

To manage this tension, PMs must give products the breathing room to evolve organically while providing stakeholders and clients sufficient stability in the future plan.

For more, see Let’s Rethink Product Roadmaps.

4. Tensions between short-term and long-term goals

There are two popular edicts that are actually at odds with each other. On the one hand, startups are told to build MVPs that test core product assumptions as early as possible. On the other hand, startups are advised to build platforms that take on a life beyond any single application.

PMs must navigate when to ship a lightweight MVP app and when to invest in a platform. Either approach can go wrong. A failed MVP could discourage a team from following a lucrative direction. A platform can be expensively built to never find its killer app.

For more, see Lean & Fat Product Thinking.

5. Tensions between religious and scientific mentalities

Inherent in many of the above tensions is a conflict from two ways of thinking about products. Lean startup methodology rides a wave of scientific product thinking focused on falsifying hypotheses and split testing. Yet, prominent product visionaries like Steve Jobs operate more like religious leaders who stay true to a mission regardless of what the world throws at them.

Product managers strive to articulate a “north star” that inspires an almost religious following. But to reach that north star, they must cultivate a scientific mindset where beliefs are discarded when disproven.

For more, see The Risk of Scientific Creative Process.

6. Tensions between employees

All of the above tensions can lead to clashes between team members. The sales team clashes with designers when both parties have different incentives under the business model. Or one team can be frustrated with another team who isn’t, in their eyes, sufficiently scientific in their approach. To manage these types of tensions, the PM must clearly articulate how the company is approaching all the above tension. This provides the rationale for how conflicts between team members should be handled.

However, the worse types of tension I’ve seen is between the identities of team members; when two people have different intuitions for how to solve a single problem. I’ve found that for teams to thrive, everyone needs their own swim lane so they aren’t competing with others over sacred turf. Yet swim lane differentiation can’t come at the price of collaboration. You need people from different swimlanes working together to accomplish singular objectives.

For more, see The Product Management Triangle.

Thanks for reading this post! Check out my project, Double-Loop, that strives to improve the product development process by recording the story of your build-measure-learn loops.





Double-Loop is an app for predicting and recording the impact of your launches. It enhances your ability to make strong bets moving forward.

The principle of Double-Loop is that your product development process will continually improve if you enact the following key behaviors.

Behavior #1: After each launch or event related to your product, record the context and its expected impact.

Consequence: You will design each new iteration with clearer objectives and measurable hypotheses.

Behavior #2:  When time passes after a launch, loop back to capture the results relative to the expected impact.

Consequence: You will discover false assumptions in your thinking and improve your ability to craft successful launches moving forward.

Behavior #3: Allow all team members to read and author the history of your product.

Consequence: Your company’s collective knowledge of the product will increase. New team members will quickly get up-to-speed with the team thought process.

Most teams, under business pressure, neglect these behaviors and fail to maximize learning. Double-Loop fixes this.

Your Double-Loop Timeline

To make this concrete, Double-Loop enables you to build a timeline of launches and other events related to your product (marketing campaigns, news events, etc). For each event, you can record the description, expected impact, and results. To illustrate, here’s a portion of a real timeline.


Deployment integration

Through integrations with GitHub and your deployment process, events are automatically added to your Double-Loop timeline when you ship code. You can set the importance of each event to elevate critical launches and minimize noise from minor tweaks.

The @Doubleloop Slack Bot

While many of us have a desire to be rigorous in our learning process, the relentless onslaught of urgent priorities leaves us little time. The Double-Loop Slack bot enables you to quickly create and update events in Slack, where you’re already living. The Slack bot makes learning easy and contagious.

Every time you ship code, the Double-Loop Slack bot will prompt you to add an event to your timeline.



You can save new information to Double-Loop directly from Slack.



The Slack bot makes it fast to update old events.



Enter the /doubleloop Slack command whenever something meaningful happens.



True organizational learning requires behavioral change. The Double-Loop app and Slack bot make learning seamless and habitual, providing a seed for cultural transformation within your company.

Wanna give Double-Loop a Try?

–> Go to the new home page

In Images of Organization, Gareth Morgan describes corporate DNA as “the visions, values, and sense of purpose that bind an organization together…”

Leaders face diminishing control as their organizations grow. DNA appears to be a good metaphor for how they can encode their core principles into the minds of their employees at scale.

I like how the DNA metaphor likens companies to species. Species persist while their members and environmental conditions change. Similarly, companies must thrive as employees come and go, as customers are acquired and lost, and as technology is refactored. Species and companies preserve life and identity while their elements radically change.

Yet, the DNA metaphor feels limited when applied in the corporate sense. Current employees don’t literally give birth to new hires, so how are genetics passed between contributors? Can you spread DNA through PowerPoint slides?

To improve on the DNA metaphor, let’s look at the broader playbook of species survival. Genetics is just one of the ways species pass along survival advantages from one generation to the next. In the Democracy of Objects, philosopher Levi Bryant writes:

… it’s worth recalling that Darwin nowhere specifies what the mechanism of inheritance is, only that in order for natural selection to take place there must be inheritance. There is thus no reason to suppose that genes alone are the sole mechanism of inheritance.

Organisms alter their environments to enhance their future prospects. There is a class of animals known as niche constructors who change their environment to suit their purposes. Beavers build dams and birds assemble nests.

For some species, survival is predicated on the non-genetic creations of their predecessors. Bryant quotes developmental systems theorists, Griffiths and Gray:

Certain aphid species reliably pass on their endosymbiotic Buchnera bacteria from the maternal symbiont mass to either eggs or developing embryo. The bacteria enable their aphid hosts to utilize what would otherwise be nutritionally unsuitable host plants. Aphids that have been treated with antibiotics to eliminate the bacteria are stunted in growth, reproductively sterile, and die prematurely.

Bryant explains:

The point here is that the Buchnera bacteria is not a part of the aphid’s genome, but nonetheless plays a significant role in the development of the phenotype. Far from the genes already containing information in the form of a blueprint of what the organism will turn out to be, genes are one developmental causal factor among a variety of others.

Key takeaway: to perpetuate your values, build them into your environment.

Here’s a simple example from my startup. We connected our post-purchase customer survey with our Slack communication system. Whenever a customer submits the survey, the Typeform app posts the response to a Slack channel where everyone sees it. Notifications are sent if the Net Promoter Score is beneath a certain threshold.

The result is that a baseline of real-time customer awareness is automatically provided for new employees. New team members don’t need to learn, “we value customer feedback” and then consciously seek it out. Instead, customer feedback is already there in the environment. Employees “inherit” an advantage out the gate that doesn’t require DNA transfer.

What examples of non-genetic inheritance have you seen work at your company?