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?




Introspective product builders can find themselves trapped in a paradox between (A) the product-driven Steve Jobs mentality of bending the world to your vision, and (B) the customer-driven lean startup mindset of adapting our products to the environment and the marketplace.

This fundamental tension in product mirrors an ancient philosophy puzzle.

The product-driven mindset echoes an anti-realist branch of epistemology where the world is a construction of our minds. Anti-realists emphasize how reality is malleable, something that can be transformed by language and concepts.

The customer-driven approach, in contrast, echoes a realist philosophy. Epistemic realists believe that there is an absolute world that exists independently of us. It is the job of philosophers and scientists, they say, to conform our mental models to the external reality.

It’s easy to say that the product-driven / customer-driven paradox is a yin-yang that requires a balancing act as opposed to a resolution. However, as someone who perpetually yearns for maximum strategic clarity, I find “balance” to be an unsatisfying answer. I’d rather find a way around the ambiguity.

In The Democracy of Objects, philosopher Levi Bryant argues that the world views of both epistemological realists and anti-realists rest upon their bifurcation of subject and object. Bryant writes:

… within the Modernist schema that drives both epistemological realism and epistemological anti-realism, the world is bifurcated into two distinct domains: culture and nature. The domain of the subject and culture is treated as the world of freedom, meaning, signs, representations, language, power, and so on. The domain of nature is treated as being composed of matter governed by mechanistic causality. Implicit within forms of theory and philosophy that work with this bifurcated model is the axiom that the two worlds are to be kept entirely separate, such that there is to be no inmixing of their distinct properties.

Both realist and anti-realist mental models anthropomorphize nature such that objects can only be understood in human terms. Their debate is only about whether or not human representations correlate to an absolute reality. Anti-realists hold that there is no such thing beyond our constructions, while realists aspire to accurately map an independently real external environment. Bryant distills the contention as the X in the following diagram.

Screen Shot 2017-08-13 at 11.40.25 PMBryant elaborates:

… this mode of distinction leads us to ignore the role of the nonhuman and asignifying in the form of technologies, weather patterns, resources, diseases, animals, natural disasters, the presence or absence of roads, the availability of water, animals, microbes, the presence or absence of electricity and high speed internet connections, modes of transportation, and so on. All of these things and many more besides play a crucial role in bringing humans together in particular ways…

Put in this light, both the realist and anti-realist philosophies seem ill-equipped to grapple with the realms of tech products where people and technologies are tangled together.

Alternatively, Bryant argues for an object-oriented ontology where human and non-human objects, first and foremost are objects. Wikipedia defines this philosophy as a “… school of thought that rejects the privileging of human existence over the existence of nonhuman objects”  The door then opens to examining, not just how machines can mimic human systems, but how all forms of human and non-human objects interact with each other. Bryant writes:

… where the anti-realists have obsessively focused on a single gap between humans and objects, endlessly revolving around the manner in which objects are inaccessible to representation, object-oriented philosophy allows us to pluralize this gap, treating it not as a unique or privileged peculiarity of humans, but as true of all relations between objects whether they involve humans or not. In short, the difference between humans and other objects is not a difference in kind, but a difference in degree. Put differently, all objects translate one another. Translation is not unique to how the mind relates to the world. And as a consequence of this, no object has direct access to any other object.

While I’ve barely touched the surface, object-oriented ontology feels like a solid foundation for product thinking. The extreme forms of both the product-driven and customer-driven mindsets give primacy to the single problem of how a company integrates with its external environment. It’s liberating to let go of this bifurcation and delve into the multiplicity of systems that require integration.  Product builders must integrate teams, technologies, customers, and business models who are all simultaneously interacting with society, culture, nature, and the economy.