Aside from the age-old debate as to whether to pre-rinse dishes before putting them in the dishwasher (hint: def don’t pre-rinse), I’ve spent very little time thinking about my home appliances. Especially my dishwasher.

Dirty dishes go in. Clean dishes come out. Why delay?

Turns out that delay feature can teach us a lot about how energy and utility markets work. And it may be a helpful tool to help us solve climate change.

Let’s take a peek into our dishwasher and see what we see.

What makes dishes clean?

So how do dishes get clean? There are a few ingredients you need.

Dirty dishes. Soap. Water for rinsing. Air for drying.

And to make the rinsing water hot and drying air hot, you need energy. Dishwashers require electrons.

Dirty dishes. Soap. Water for rinsing. Air for drying. Electrons.

And those electrons need to be generated somewhere, using some sort of fuel. That fuel could be the sunlight kissing your solar panels, a warm western breeze turning a windmill, the cool waters of Lake Eerie falling over Robert Moses Hydroelectric dam…or pile of coal being shoveled into a coal furnace in Kingston, Tennessee.

And because the electric grid requires supply and demand to be balanced, the electrons that your dishwasher is using have been generated very recently (within ~5 minutes).

So the beauty of this Delay Start feature is that it allows you to control when those electrons get consumed. In the words of General Electric, “The benefit of the Delay Start option is that it allows you to run your dishwasher when its hot water demands will not conflict with those of the family. It also lets you take advantage of off peak utility rates.”

The general concept here is known as Demand-Side Management, or Load Shifting.

Between the time I load my dishwasher and am ready to unload my dishwasher, I don’t really care when the dishwasher runs. Which means we have flexibility to control when these electrons are consumed. And if we’re optimizing for minimizing our personal carbon footprint1, that means we can consume the electrons that are generated by the least carbon intensive fuel.

How many electrons are we talking about?

By looking at my home energy usage, we can get to an estimate of the load profile for my dishwasher. We see on nights that we run our dishwasher, our energy consumption spikes by +0.5 kWh for 2 hours. We have a GE Adora dishwasher has a 118 minute “normal” runtime and is estimated to consume ~1.12 kWh per load. So the EnergyStar estimates and reality are looking pretty close.

When’s the carbon-optimal time to run my dishwasher?

Let’s answer this question for an individual.

First, let’s start by finding the worst time to run your dishwasher. The worst time to run your dishwasher is when the incremental demand directly correlates to the most carbon-intensive fuel is being burned to generate the electrons to power your wash cycle.

In California, because solar provides such a large supply of clean energy during the day, the worst time to run your dishwasher would be when demand is highest and renewable supply is lowest. At these points, every incremental ask for more electrons need to be supplied by carbon-intensive fuel.

On most days in California, that’s around 6-7am or 7-8PM, when the sun’s down and everyone is at home cooking, showering, watching TV, doing laundry, and…considering washing their dishes.

So the optimal time is the inverse of this, in which the most renewable supply is available and demand is the lowest. Most days in California, that’s appears to be ~2-3PM.

Of course, this assumes no real-world constraints, like when your dishes get dirty and whether you need dishes to eat your dinner. If you want to run the dishwasher overnight, 2AM seems like the sweet spot when net demand is lowest.

What if you were a Dishwashing Demigod?

Now let’s pretend you are an almighty Dishwasher Demigod. No, you weren’t blessed with control over the Sky or Sea or War. But you have one very important superpower — ultimate and final control over when to run all dishwashers in the universe.

Let’s constrain our analysis to California and assume there are 7.2 million dishwashing machines that need to run every day2. How will you, as all powerful Dishwasher Demigod, allocate this 8MWh load?

The answer is almost certainly to schedule all dishwashers to run between 11a-4pm. This is when net demand is at it’s lowest, which means incremental demand can be serviced with low-carbon alternatives3. 8MWh, while sizeable, is And by creating predictable demand, CAISO could include this demand in its forecast models to ensure optimal capacity.

Clean ya dishes at 2PM

There are obviously a lot of other factors to consider when thinking about when the optimal time to run the dishwasher. Grid-scale batteries, renewables fuel mix for your region, weather, and water levels can all play a role. And it’s fair the assume that the least carbon-intensive dishwasher cycle is the one that never happens. So if you can skip a cycle or enjoy a crusty patina of last night’s dinner on your bowls, do that.

But if you must run your dishwasher, think about using that delay start feature to schedule the cycle when net load is at it’s lowest. That’s usually 2am or 2pm!

Thanks to Baker Shogry, Calvin French-Owen, Chris Nixon, Alexia Niparko and Simon Greenberg for reading drafts!

Speed, Scale & Climate OKRs

I’ve been making my way through John Doerr’s Speed & Scale, which examines the climate crisis and proposes a set of OKRs to help guide us to net zero by 2050.

There’s a lot to love about this book. John provides one of the simplest (and familiar, for those who have used OKRs) frameworks I’ve come across for thinking about how different climate solutions fit together to avoid climate catastrophe. He also frames potential solutions as measurable goals, which gives us a way to track our progress toward solving the climate crisis.

At Segment we organized our annual & quarterly plans around OKRs, and there was one major indicator of whether an OKR would be achieved: whether the team had built a dashboard to measure progress towards the key result1.

This week, we’re going to build a climate dashboard together.

We’ll focus on the Speed & Scale’s Objective #6: Remove Carbon: Remove 10 gigatons of carbon dioxide per year. This is based on a 2017 UNEP report that estimated we’ll need annual CDR of 10Gt will help achieve a 2°C scenario.

If you are unfamiliar with CDR, I’d recommend checking out CDR Primer to learn more.

“D” Stands for Data

Sooooo where’s the data? Good question, as climate datasets tend to be fragmented, unstructured & stale.

CDR today is largely purchased by private companies (“Buyers”) and removed/stored by private companies (“Sellers”). This is essentially a marketplace, where you have corporations on the buy-side looking to offset their emissions, and CDR Sellers on the sell-side removing CO2 from the atmosphere and finding ways to permanently store it (in soil, rock, water, cement, or injecting it underground).

Luckily for us, Robert Höglund at Marginal Carbon has done much of the heavy lifting to assemble a dataset of publicly announced purchases of durable (100+ years2) carbon removal with storage3. This includes seller, buyer, method, how much was purchased, and even how much the buyer paid in some cases.

There are definitely some limitations to the data, but it’s a great place to start to understand the state of the CDR market and measure our progress toward our 10Gt / yr goal by 20504.

Building our dashboard 📈

Let’s take a look at what we were able to build 😍

Headlines

In total, there have been 69,349 tons of durable CDR purchased. 48% of that 69k has been delivered, the other 52% are purchases for future delivery. And as a percentage of that 10Gt / yr by 2050, we are only 0.0000074% towards our goal.

But we need to start somewhere!

Who’s Buying & Who’s Selling?

On the supply-side, there are 30 sellers. Charm Industrial had sold the most tons (~13k) followed by Direct Air Capture companies Carbon Engineering (~11k) & Climeworks (~10k). The top 7 Sellers account for 80% of all CDR sold, so supply is heavily concentrated in just a few companies.

On the demand-side, there were only 12 Buyers, most of which are corporations. Shopify, Patch5, Stripe, and Microsoft are the biggest buyers.

How much does a ton of CO2 cost?

With the cost data, we can derive how much a ton costs from different Sellers. The average cost is $332 per ton, but there are a few reasons we should be skeptical of this number. The first is that many of these agreements are proofs-of-concept, so this doesn’t represent the true cost of a scaled solution.

Using this average cost for a ton of CO2 ($331) x tons purchased (69k), this puts the total CDR Gross Merchandise Value (GMV) ~$20-30M.

The range of $ / ton is wide. At the lower end, Project Vesta is $75 / ton with to $2k / ton with Ebb and Heirloom.

We’ve launched a live version of the dashboard! You can find it at cdr.fyi

Takeaways

• For us to achieve our climate goals, we need to set clear and measurable goals. We also need to share the data & report on progress.

• CDR data today is largely self-reported and unstructured, which limits our visibility into progress. There’s an opportunity to create data & reporting standards that can provide us

• The CDR market is still very early! 30 Sellers, 12 Buyers, $20M transaction volume, 69k tons, .000074% where we need to be. Exciting progress and healthy competition among Buyers & Sellers is going to help lead to a cooler climate.

Team states are defined by two dimensions. The first is the pace at which new products & features are developed and delivered to customers (”shipping”). The second is the impact that those products & features have for customers, in the market, and on your company’s trajectory.

The state of a team is a combination of a bunch of different ingredients: the market you’re going after, company culture, exec leadership, product strategy, organizational incentives, and the members on the team. Team state is rarely caused by any given team member, or any one factor.

Teams naturally move between states as the market, company, strategy and internal incentives evolve. Some states are stable and can remain in a state forever (e.g. not shipping). Some are unstable, with structural reasons why they will not persist (e.g. teams shipping high-impact products are prone to talent drain)

States are not sequential. Teams need not to move between them linearly.

A product organization can and will have teams in various states. A product leader can be measured by their ability to consistently move teams to a desired state, and keep them in that state.

To understand why a team is in a particular state, you first need to understand the underlying conditions and factors that caused the state. For example, a team that’s not shipping could be due to attrition, tech debt, unclear strategy, inability to hire, missing skills, bad incentives, internal team tension. To move a team to a new state, you need to change the underlying conditions.

Let’s look at each state and ways in which a product leader can help change state.

Your Team Doesn’t Exist (Yet)

This state is where all product teams start.

In this state, there is The Idea but there is no team dedicated to pursuing The Idea. You (and perhaps a recruiter) are responsible for building the team that will turn The Idea into a product.

This state is independent of whether The Idea is a good idea or a bad idea. It’s independent of whether The Idea is a broad problem to solve (best case) or a specific product that someone thinks is a good idea (worst case).

There are two paths out of this state.

The first path out is to invalidate The Idea. This can save you months and years of your life trying to build something nobody wants. Go talk to customers. Prove or disprove your hypothesis. Build a prototype and actually test whether The Idea solves the problems you think it does. Killing The Idea is the fastest way out of this state.

Your second option is to build your team, which means you need to hire. Hiring in this state is tricky because it’s a “cold start”. You don’t have much momentum or validation that The Idea is worth anyone’s time. You don’t have other teammates that can help sell candidates. The best thing to do is to develop a clear vision and hire a team of folks who are excited about the vision and willing to take a risk.

The other thing to optimize for in this state is flexibility around The Idea itself. This can be internal (not letting yourself get too attached to any solution) or external (not letting the org pre-define a solution). That flexibility will allow your team to have more ownership and creativity to expand, iterate, or even change The Idea once hired.

Your team doesn’t consistently ship

In this state, you have a team but they do not consistently deliver new products, and are not iterating on existing products and features in meaningful ways.

There are many conditions that can lead to this state. The team can be working on a multi-year project. They may have shipped something that caused a SEV and are fearful to ship again. They may be carrying a lot of tech debt, that makes it difficult to ship.

The challenge with this state is that it’s self-reinforcing. This state falls prey to a perverse version of the Lindy Effect: the longer a team doesn’t consistently ship, the longer a team will typically go without shipping. That’s because teams in this state do not have access to all the benefits of shipping (positive customer reactions, release parties, the excitement of launch day) and the muscle required to deliver products to market will atrophy (don’t know the process, unclear how market or leadership will react).

To get out of this state, first you need to understand the underlying causes. There are two strategies that can be help you understand those. The first is to get the perspective of the team, to encourage them to share their problems. The second is to find the smallest possible thing to ship, and work with the team to ship it. Doing so will highlight where the friction is, while also building the shipping muscle.

Your team consistently ships low-impact products

The key to this state is that the pace of development is good, but the quality and impact of the products is poor. This can take many forms: products can be unstable, prone to outages, not solve a clear need, too expensive, and not have the right user experience. There are many ways to create low-impact products.

In smaller organizations, low-impact products are typically a symptom of lack of focus. Teams are moving too quickly and not enough validation, architecture design, diligence, QA, and testing are being invested into what’s being built. In larger organizations, low-impact can be a symptom of incentives and culture that celebrates splashy launches over measured impact of those launches.

To change state, you need to change incentives and culture. One way to do that is to introduce metrics & dashboards that emphasize customer impact and stability that the team can use to measure their own performance.

Your team consistently ships high-impact products

Teams in this state are high-context, high-trust, and high-talent density. They work closely with customers and feel empowered to take risks. They are consistently delivering products and features that delight customers.

There are two reasons why teams will not tend to remain in this state.

The first is that the mission of the team will naturally evolve as the product (or project) progresses. The initially value prop that attracted team members will erode. The excitement of building a new product, or fixing a long-standing problem in the infra, will cease to be the work. The product has been built. The infra scaling challenge solved. Team members will seek out new challenges.

The second reason is that you (or other leadership) may be tempted to “spread the talent out”. You may want these team members to go teach teams that aren’t shipping how to ship, or to go build their own teams. These changes may be best for the org, but risk changing the state of the team as members are redirected to new challenges.

Team states are malleable

As a product leader, you can and will change the state of your product teams. Team states are malleable. As conditions change, so to will the state of your teams. By understanding these states and being thoughtful about state change, you can build an org of product teams that consistently ship high-impact products.

Climate & citizen researchers should be able to easily access trusted, comprehensive climate datasets to understand how the climate crisis is unfolding and what can be done to stop it. Unfortunately, the state of climate data is highly-fragmented, ungoverned, and unmanaged.

Problem

The climate crisis is evolving rapidly. Since you started reading this memo, roughly 10,000 tons of CO2 were released into the atmosphere from fossil fuels.

Our efforts around the climate crisis is also changing rapidly. In 2021, climate tech companies raised over $30B. The academic community has published ~4,000 papers per year on the climate change since 2000 (many containing important datasets!). From EVs to kelp farming to satellite methane mapping...climate research, climate business models, and climate data is exploding.

Unfortunately, the climate data we need to measure our climate progress is...

• fragmented: Climate data often lives squirreled away in a PDF on a research labs website. It is unstructured. It takes time to find if the dataset exists, what format it’s in, and what licenses data has been released under. For example, CAISO provides hour-by-hour fuel mix in .csv format...but the files are partitioned by day. Answering questions like “what was the mix for October

• unstructured: Climate data is frequently unstructured and ungoverned. Because there is no central standards for publishing climate data, timeseries data dates will be formatted however the publisher wishes. Same with geographic regions. This lack of standardization makes combining datasets tedious to impossible.

• stale: Climate data is frequently outdated. Determining what the carbon emissions today is impossible. And for data that is published in near realtime, you frequently have to query and munge the data manually, introducing delays into your reporting / models.

  

At Segment, we had a rule that any data we wanted analyzed needed to be in a data warehouse. Sure, our analytics team could export data from various internal data stores or hit an internal API for data. But often the difficulty of accessing that data was enough of impediment to deter even the bravest analysts. The available data gets analyzed; inaccessible data gets stale.

We need a climate data platform (CDP!) that can...

• ingest public climate data (keeping it up to date as new data is published)

• structure, standardize and index the dataset

• allow researchers to query and combine that data to answer questions, monitor progress, and build on each other’s work

Demo

For this demo, I manually loaded some interesting datasets into BigQuery and used Mode to query/visualize.

Let’s take a look at the biggest emitters of emissions by sector in the US. CarbonMonitor provides an open-source data set and they have a cool dashboard feature on their website, but it’s limited to the pre-populated charts.

US Emissions by Sector

So let’s use Climate Analytics and write some SQL:

Boom! Looking at data since January 2019:

Now let’s visualize it...

Woah!

• Note the winter seasonal spikes in Residential (dark blue)

• Interesting the Power Sector tends to spike during the summer (red)

• Check out the covid-19 dip in April 2020

• And if we look at this on a % basis, Power + Ground Transportation account for 64% of total US emissions

• I would looooove to join in weather data here to see how correlated emissions spikes are with heat waves / cold snaps

US v. China Industrial Emissions

Alright, second question. Let’s go global and compare US v. China industrial emissions...

Anddddd chart it...

• Chinese Industrial sector 3-4x emissions of US industry

• Note the troughs every year in early Feb around Chinese New Year

• Also check out the “COVID offset” as China shut down in 2/2020 and US shut down in 4/2020

All this goodness off just one dataset!

Let’s add in some CAISO Data

CAISO provides csv extracts of daily fuel mixes (note: the CSV dates aren’t formatted properly so had to do some cleanup!)

Alright, now let’s look at total US emissions from the power sector (from carbonmonitor )x biogas fuel mix from CAISO. With a simple join...

These two datasets have never been viewed before! (that I know of 🙂)

What’s the dream state?

• Realtime data feeds of every emission + sink + global climate accounting dashboard

• Data scientists + analysts are able to access data to build/share models + dashboards

The Problem

• For a time horizon of 100 years, CH4 has a Global Warming Potential 28 times larger than CO2. Each molecule is 84x more warming than CO2

• Methane is responsible for 23% of the global warming produced by CO2, CH4 and N2O in the 20th century.

• The concentration of CH4 in the atmosphere is 2.5x above pre-industrial levels (750ppb —> 1800)

• Methane remains in the atmosphere for ~10 years (though exactly how long depends on atmospheric hydroxyl radical levels, of which we don’t have a great way to measure). This makes methane a big lever to reduce warming as reduced emissions —> reduced warming within a decade.

  • Stock v. Flow: Stock gases are long-lived and build up in the atmosphere (e.g. CO2). Flow gases are naturally removed from atmosphere over time (e.g. CH4). Solve the flow problem for methane and you solve the warming problem within the decade.

• Concern that melting permafrost may contain high levels of methane ("methane bomb") that is emitted as planet heats up and ice caps melt.

• “Million paper cut” kind of problem: Methane emitters are usually diffuse (manure fields, abandoned mines, municipal landfills) and while the tech isn’t hard (“more plumbing v. rocket science”) requires policy > behavior change > enforcement.

Methane Budget

• Each year we emit a net ~16.8 Tg CH4 / yr. Natural + human emissions of ~592 Tg / yr and sink ~571 Tg / yr.

• Emissions: Ag, Fossil Fuel production represent anthropogenic sources. Wetlands & Biomass Burn represent natural sources.

• Sinks: Soils + Atmospheric Reactions (see below) are the major sinks

  

Opportunities

CH4 warming mitigation represents a potential short-term fix for global warming, as methane traps a lot of heat per molecule but is relatively short-lived. Reducing methane levels can buy us more time to scale up carbon capture. Number of atmospheric molecules you'd need to reduce is much smaller than CO2 (but also far more diffuse)

• Methane Emission Reduction strategies

  • Measuring Methane Leaks: Key ingredient to reducing methane is to be able to detect leaks in industrial process. MethaneSat is launching a satellite + data platform for monitoring methane concentrations globally. CarbonMapper and JPL already provide a public dataset to explore. One of the interesting opportunities is to use this mapping tech to allocate and enforce international policy commitments in ways not previously possible with carbon.

  

  • Natural Gas > Electrification: Stop installing gas cooktops and gas furnaces, and substitute electrical appliances

    • Warning on alt uses for Natural Gas: Do not start using natural gas to produce hydrogen, even if you’re capturing the carbon emissions from the process. This so-called “blue hydrogen,” beloved by oil and gas companies, and included in the bipartisan infrastructure bill, does not cut global-warming emissions, in large part because of the methane that vents out in the process

  • Cow Feed Additives: Reduced methane emissions from cattle with (Mootral), e.g. garlic & citrus extract has been shown to reduce methane emissions of cows by ~30%

  • Flaring: converts methane leaks to CO2 (Frost Methane). Sounds a bit dirty but can reduce equivalent CO2 emissions by 98%

• Methane Sink strategies

  • Enhanced atmospheric methane oxidation: Methane Action is looking into ways to use bunker fuels (emitted from ship stacks) which contain iron. Iron, sunlight + salt-sea spray generates a mix of iron trichloride and chlorine atoms, which may oxidize methane. This is just one of many sources of iron, but you need concentrated FeCl3 concentration to oxidize methane

    

  • Methane oxidizing bacteria (e.g. Methylocapsa gorgona, found in soil) can oxidize atmospheric methane. We haven’t been able to successfully cultivate this bacteria to scale CH4 oxidation

Questions

• What prevents us from measuring atmospheric hydroxyl radicals levels?

  • Mystery: Methane is naturally oxidized in the atmosphere by hydroxyl radical (OH). CH4 levels plateaued around the year 2000 before resuming globally in 2007. We are unable to measure presence of OH at scale, making it unclear how long methane remains in the atmosphere

• What’s the limiting factor on scaling methane-oxidizing bacteria?

• Is there a way to create a realtime dashboard of methane emissions attributed to the source based on satellite data?

Resources

• Much talk of CO2, but what about methane?!—w/ Olya Irzak of Frost Methane

• Methane Action

• After 2000-era plateau, global methane levels hitting new highs

• Are We Finally Ready to Tackle the Other Greenhouse Gas?

• Widespread soil bacterium that oxidizes atmospheric methane

• A nature-based negative emissions technology able to remove atmospheric methane and other greenhouse gases

• Volts podcast: all about methane, with Sarah Smith of the Clean Air Task Force

Sharing a few reflections on some of the tips and tricks we found helpful along the way...

0. Great product ideas are built by teams that listen

Listen to your customers and they will tell you their problems. They will share the solutions that they have built themselves, that no one else has figured out. They will tell you what problems they don't have, that you mistakenly thought they had.

If you want new product ideas, talk to your customers with no other agenda than to listen

1. Record Every Call

I learned this from Micheal Bamberger (CEO of Tetra Insights) a few years back, who was horrified to learn we weren't recording our research calls. Research calls are messy. Lots going on between taking notes, thinking about where to take the convo, understanding what the person is telling you.

Recording (and using a tool like Tetra) helps you be more present, bc you can always go back to tape & transcript

2. The more you summarize, the less customer empathy you build

There's this interesting tension in synthesizing research. Most people don't have time to listen to the raw interviews...but the more you compress those interviews into bullet points the less empathy you build.

The beauty of qualitative research is that it can be emotional. You can hear the sense of excitement or frustration from you customers. A chart or slide deck summarizing your findings cannot compare.

3. Find the Money Quotes 💸

Highlight reels and "money quotes" are the perfect pairing for research synthesis. We actually played customer interview highlights at company all-hands so everyone can share in the experience of being with our customers.

Wherever possible, share highlights of the raw research over summarizing

4. Card Sort, Surveys, Stickies, Oh My!

There are many more research tools available beyond plain vanilla customer interviews. We used a card sorting exercise @optimalworkshop that got us nice structured data.

It's easy to default to customer interviews but there's much more out there!

5. Everyone wants to talk solutions (including you!)

Part of customer research is wading in customer problems and ambiguity. In almost every conversation, customers, our team, and x-functional stakeholders wants to talk about how to fix problems. It's uncomfortable to stare at problems for so long, but it can bring new clarity and highlight assumptions if you get it right

6. Host a readout session

Another one that seems obvious but not done enough. Hold an open session to share your findings with the org. Put it in the calendar a few weeks and use it as a deadline.

You can generate new insights build org context by getting other folks to discuss and debate what you learned

This post marks the 12th essay I've written & published in 2020. One post a month (though I started late and crammed in December). I have finally fulfilled my writing resolution of 2017 🙌

I've found writing to be an incredibly fulfilling way to spend my quarantine, and I want to share the practical lessons I've learned from (most failing) to develop a writing habit. There's plenty of good resources on how to write (recommend here, here, here, here), so this isn't meant to be a comprehensive how-to guide for starting a blog.

But if you're thinking about starting a writing habit in 2021 or stuck in a rut on your writing, here's how I overcame it.

Multiplayer Writing > Single Player

There was one takeaway that rose above the rest: writing is better when you write with others. Your essays will get better with crit and revisions, yes, but the experience of creating the essay is more fun when you write with friends.

The trope of the recluse writer returning from the cabin with a masterpiece in hand is eclipsed many-fold by the press rooms, the writers workshops, the smokey Parisian writing clubs. For many years I thought I needed a cabin and some quiet, when in reality I needed a crowded and busy writers’ room.

We started a writing community in our work slack channel for people trying to write more (#yolo-writers). It became a place where you can share a rough draft and get honest feedback on it. It created accountability (and FOMO) when everyone is sharing their drafts and publishing. It's a messy exchange of ideas on all kinds of topics that people are thinking about, but there is no shortage of new connections and ways of thinking about the idea.

Having a personal "editorial board" is helpful for a few reasons. The first is that it builds confidence, because you share your post with someone who is not you and they will typically have (at least some) nice things to say. The second is that they help you unpack the important pieces of the post.

Our #yolo-writers channel turned writing from single-player game into a multi-player game.

Build Your Writing Funnel

One of the ways a "funnel", or series of steps you need to go through to get your ideas out into the world:

1. Idea - first you need to pick something to write about, which can be a challenge if there are no constraints.

2. Draft - this is where you take your idea and bang out a first draft. It requires hands on the keyboard, good space to think, and a touch of inspiration

3. Edit - You need to take what is unlikely a good first draft and turn it into something that you think is valuable (either to the reader, or yourself)

4. Publish & Share - You need to hit the Publish button, and see the post live on the internet, and share it with folks

By thinking about your essays as a funnel, you can figure out where you are jammed. Do you not have enough ideas? Are you not converting those ideas into drafts? Does it take too long to edit them?

Here's a snapshot of my writing funnel stats. You can see that I have a backlog of ideas for blog posts, a bunch of active drafts, a few in the Editing, and 11 published.

This is a pretty different approach to writing than what I've come across in school or work. In those contexts, there is a clear assignment and corresponding topic. There's a due date. With personal writing and essays, all of these constraints are relaxed so you can pick ideas up write, and edit as you please.

Ideas 💡

I have many more Ideas than I have Drafts. That's because (a) many of my Ideas are not actually interesting enough to warrant an essay and (b) it's a lot easier to add an idea to my list than to write an essay.

I like to have a place to put ideas as they come up. I have a Notion writing board and I'll create a new post with the headline as the idea, and link to whatever made me think of the idea. Sometimes I'll add some initial thoughts, but at this point I really just want to capture the idea and return to it later when I'm ready to write.

There's a great segment on This American Life, where Ira Glass goes into the writers room at The Onion. The writers go through a brutal process every week of creating over 600 headlines for the satirical paper, only to whittle the list down to 16 articles that actually get written. The problem is that many of the headlines are funny on the surface, but there's no depth to the joke.

I've found the same with essay ideas. By the numbers, only about 1 in 5 of my ideas have actually materialized into an essay. This isn't from a lack of trying, many of them just don't go anywhere. Which means that ~80% of the ideas I think are good at the time, turn out to not be viable ideas at all!

Ideas will come throughout the day — on a run, in a meeting — so it's good to have an easy way to capture and figure out if it's a good idea later.

What topics should you write about? "Write whatever you want!" is not super helpful, but is the reality when starting out. This turned out to be the biggest impediments for me when getting this project off the ground. I didn't think I had a unique perspective on a particular topic. But I was pleasantly surprised to see how that vague concern came crumbling down.

It turns out that nobody sees and thinks about the world the way you do. Every thought and problem you've solved is unique to your experience. By sharing your experience, you can hear from others who have faced similar challenges and came to different conclusions, or can use your experience to guide their own.

There is a specific type of idea that I've found really fulfilling, and easy to write. "Project" posts document a specific project that you've attempted. It can be big, or small, functional, creative, engineering, art, analytics, home improvement. It doesn't matter. Abstract Capital and Squatbot are two examples this where the bulk of the work is in working on the project. Just make sure you document as you go!

Draft ✍️

Once I had an ideas board going, I'd pick an idea and write a first draft.

Your first draft is going to suck. You will probably despise the idea by the time you are finished with your first draft. You will regret your decision to write at all. It's pretty painful.

As I write these words, I am filled with self-doubt. Is this point I'm making here so obvious? What do I know about blogging? It's natural in the draft stage to feel impostor Syndrome. Push through.

The best advice I can share is to think of this draft as 30% "done"-ness of what you will eventually publish. This can help alleviate some of the self-inflicted doubts and writer's block that comes with aiming for perfection. Your goal is to sketch out the idea, not to write a Pulitzer-winning piece.

I've found weekend mornings — after the first cup of coffee begins to kick in — to be the best time to pull up my ideas board and start drafting.

Edit ✂️

Next comes the editing process. I like to let my Drafts air out on the shelf for a day or two after writing. I'll re-read and edit for clarity, before sharing with my "editorial board" (aka #yolo-writers)

At work, we created a slack channel called #yolo-writers with a few folks who were interested in writing more. Whenever anyone is ready for feedback, they share in the channel and a few people respond with feedback. We loosely follow the "ABCD" framework for giving feedback:

Here's an example of the type of feedback you can get in #yolo-writers (from Osama):

Publish & Share 🖨️

Hit the button! I am admittedly not great at marketing what I write. I write because it's personally fulfilling and helps clarify my thinking, so I'll point you to some strategies that Lenny Rachitsky recommends on building his newsletter community. But it's a really great feeling when someone references or engages with something that you wrote. Remember that feeling next time you're procrastinating or feeling embarrassed about a draft.

KYSS

Keep Your Stack Simple. KYSS. I repeat: Keep Your Stack Simple.

There was a point during the year where I was running Google Lighthouse tests to figure out how to optimize my page load performance for a Next.js app running on Vercel powered by a Notion backend. I wanted some analytics so I got Segment implemented and built a dashboard in Amplitude.

Worrying about my writing tech stack turned out to be a very good way to distract myself from actually writing. This is a common trap I've seen others fall into. My only advice is to recognize that this is a means of procrastinating, take a break instead of falling down an optimization rabbit hole, and come back when you're ready to write.

In the end, I simplified:

• I write and edit in Notion

• I draw diagrams in Excalidraw

• I publish on Substack

There's a bit of copy-pasting between Notion —> Substack to get a post live, but I like being able to keep the Writing Funnel on a board in Notion and prefer the editor.

Write for Your Why

There are a lot of reasons to write more. It can help clarify your thinking, sharpen your ideas, build your community, release the pent up ideas in your brain. Reflecting on the reason why you're picking up a writing habit can help quell the internal excuses that are preventing you from doing it. At the end of the day, the why is personal.

If you are just getting started...don't write for others, write for yourself! The biggest mental blocker I had was in trying to fulfill some vague expectation of (future, imaginary) readers...when in reality, the value came from the messy exchange of ideas (internal and external) that is writing on the internet.

I hope my essays help others in some small way. That they can apply an idea to a problem in their life. But if they don't, I am 100% content to have written it down and shared.

And for those who are planning on writing more in 2021, I wish you the best of luck. I am happy to brainstorm, edit, or commiserate anytime.

The project you're working on probably doesn't matter. The PRD you're writing probably will not have the intended impact. Your next 10 meetings are immaterial to your customers, and your business.

Often these decisions — the ones that don't matter — reveal their lack of importance only in hindsight. We were tweaking the price tag when we had the wrong business model. We were debating UX optimizations when we didn't have product-market fit. We expected the customers to be more upset — or delighted — than they were. Turns out they didn't care.

Why do we spend so much time solving problems that don't matter, and what are some strategies to avoid it?

The Importance Trap

The seemingly important-ness of the problems we're solving is a trap.

It starts with you, the hero of the story. You start thinking about something, most often because someone asked you to start thinking about something.

"Hey, a customer is asking us if we can support X. Wdyt?"

You haven't really thought about X much, and so you start doing some research. Maybe you talk to the customer to learn more about X. They confirm that X is important to them.

To support X, you'll need to spend some time building X. That will have to tradeoff against the work that you're already doing building Y, which you previously thought was important. To make this tradeoff decision, you'll need to do some additional research and figure out the Return on Investment (ROI). A decision like this needs its due diligence, after all!

You've fallen into the Importance Trap. This trap follows a pattern...

1. X is introduced by some exogenous force (customer, sales, Twitter)

2. You decide to "quickly explore" X

3. X is bigger and more complicated than you thought, so you need to think thru complexity

4. I've invested a lot in thinking about X — and convinced others to think about X — so it would be a waste to abandon X

Why we fall in to the trap

There are a few psychological biases that contribute to the Importance Trap.

Recency bias and desire to people-please push us into the Importance Trap, and our desire to remain consistent and avoid losses is what makes it a Trap.

Recency Bias

Problem X is staring us in the face. It's an email in your inbox from a sales rep saying the deal hinges on X. It's a conversation in a meeting with you CEO. The recency of the problem can jumble up the priority.

People Pleasing

Often the introduction of Problem X comes from someone we like, or trust, or want to make happy. It can be uncomfortable to explain the tradeoff that you'd have to make from solving Problem Y, which they may not know or care about.

Consistency Bias

People have a strong psychological drive to appear consistent with what they've already done. This means that we have an innate psychological drive to do things in the future based on what we've committed to in the past. So by the very nature of publicly committing to exploring an idea, it becomes harder for you to abandon pursuing the idea in the future.

Loss Aversion

Once we've spent a bunch of time in the Importance Trap, it becomes harder and harder to get out — because we would have to admit to ourselves that we wasted time, resources, energy, dollars exploring this idea.

How to avoid the trap?

So, how can you avoid the trap, and avoid spending time on low-impact problems?

Define your North Star ⭐

Pick something that you care about and declare it your north star. Share your north star with others. It could be a large-scale social problem (world hunger), a thing that you care about (raising a great family)...this is your fundamental "why" that motivates you.

Apply the Hallway Test 🧪

A former manager of mine used to talk about the "Hallway Test". The idea was that at any point, someone stops you in the hallway (back when there were offices!), and asked you where you were heading.

In a few sentences, you should be able to tie the thing thing that you're doing (task) to your North Star. For example: "I am going to a meeting to discuss our hiring plan for the next year because we need to grow our team in order to build this new product which will allow small businesses to bring their brick-and-mortar stores online, which will allow more people to participate in the digital economy, which I believe is the best way to reverse financial inequality in society"

Ruthlessly Prioritize your TO-DO List ✂️

The problem with most TO-DO lists is there is almost no friction to get something on there. "Add and prioritize later". This means that the TO-DO list becomes a dumping ground for low-impact ideas. There are many tricks to do this (Urgent-Important Matrix), but all should pass the Hallway Test.

Don't Fall In

Over the course of a Product Manager's career, the Importance Trap can distract from actual important problems with seemingly-important but low-impact problems.

By aligning yourself with a North Star, and being ruthless in ensuring that your priorities align with that North Star, you can avoid falling into the Importance Trap.

The strategy is pretty intuitive. Continue to break down a problems until you can't break it down any further. Only once you've broken problems down to their smallest part do you brainstorm and test solutions.

It goes something like this...

function decompose(problem p) { 	   
  let subproblems = p.subproblems() 	   
  if (subproblems == null): // can you break the problem down? 		         
    return brainstormSolutions() // brainstorm solutions 	   
  else:		     
    return decompose(subproblems) // if so, decompose again!   
  }

By being disciplined about following this algorithm, I believe everyone can improve both the rate, the quality, and the level of ambiguity of problems to solve. Let's explore it a little more and see it in action.

The Problem with Most Problems

The problem with most problems is that they are presented at a level that's unsolvable. It is through decomposing that problem into smaller units that it can be understood and ultimately solved.

Why isn't our business growing faster? Why are our customers churning? Why am I not finding good candidates to hire? It's easy to fall into the trap of guess-and-check, to jump to solutions that could solve this problem. But by systematically breaking down problems into their atomic parts, you're more likely to find the non-obvious solutions to the problem.

When faced with a problem with a ton of ambiguity, unpack the problem into a series of smaller sub-problems. The first step, decompose!

"Our business is not growing fast enough because (a) we are not adding customers fast enough, (b) our churn rate increased last quarter, and (c) we're buried in support tickets."

That's where many — myself included — fall into the Ideas trap. The mind naturally starts to brainstorm ways they can solve these sub-problems.

We can host a webinar! We can add a self-service option! We can make our docs clearer!

Most people will have reasonable ideas about how to solve each sub-problems. And they will probably be right, some of the time. But until you have the map of all the nubby sub-problems, it's still unclear what needs to be solved

But what if we decompose these sub-problems again?

Well, it turns out we are not adding customers fast enough because we're not reaching out to our leads fast enough. And customers are churning at higher rates in Europe because of a new regulation. And our support load is largely driven by non-paying customers who use Advanced Feature #7.

Can we break these problems down any further? If the answer is yes, and that will lead to better insight about the problem itself, then do it. If not, we've achieved problematomicity. We've reached the end of the line, the problems cannot be broken down further. They are indivisible.

At this point, we can begin to brainstorm solutions for the atoms that comprise the larger problem.

Example: OPower

An example of this type of recursive problem solving I saw recently is this 2016 talk by the OPower data science time. I recommend a full watch, but the "problem" they set out to solve: how do you get people to consume less energy at home, to help reduce climate emissions?

Well, to answer that question, they start by understanding how people consume energy. They go out and get the data for the energy consumption patterns of households in an area. You can see this charge below. They refer to this as the "hairball" chart, because it's so overloaded and hard to discern what's really going on.

I find this to be such a great visual representation of an ambiguous problem:

A spike means the household is using lots of power during that period of the day. You can see how power usage falls off at the end of the day, when people go to bed.

But the team at OPower decomposes this problem! By using a clustering algorithm, they find a few common usage patterns in the data:

They decompose the "hairball" into 5 archetypes. With these different archetypes in hand — the night owls who use energy at night, the twin peaks who consume before leaving for work/school and when they return — they decompose again!

They figure out what drives usage for each of the household archetypes. For example, the Twin Peaks archetype using energy in the morning and at night. This typically aligned with working families, getting the kids ready for school and making dinner at home after work. But an archetype like the Steady Eddies were more likely retired or stay-at-home, using energy evenly throughout the day.

They decompose the "hairball" into 5 archetypes. With these different archetypes in hand — the night owls who use energy at night, the twin peaks who consume before leaving for work/school and when they return — they decompose again!

They figure out what drives usage for each of the household archetypes. For example, the Twin Peaks archetype using energy in the morning and at night. This typically aligned with working families, getting the kids ready for school and making dinner at home after work. But an archetype like the Steady Eddies were more likely retired or stay-at-home, using energy evenly throughout the day.

By unpacking the hairball chart into a series of sub-problems, OPower was able to solve their top-level problem by delivering targeted solutions that aligned with the sub-problems they came across in their research.

Common failure modes

So why do people exit the loop early, and settle for solutions before understanding the full breadth of the problem. The common failure modes I've experienced...

• Idea Trap: you get impatient and jump to solutions too early. This can be solved by being disciplined about following the algorithm, and getting others opinions on whether you've reached the deepest depths of the problem space.

• Data isn't readily available: breaking down problems often requires exploring data. Data can be unavailable, low-quality, untrusted, or hard to collect. This can add additional step to the recursive loop. In the Opower example, the first step was actually collecting the meter data to understand how people use electricity throughout the day.

• Lacking context: Decomposing problems in meaningful ways often requires high context. Do you break a problem down by geo or industry-verticals? should you focus on supply-side or demand-side? Context drives good hypotheses that accelerate problem decomposition. Lack of context means you have to explore more lower-probability hypotheses.

1/ solving customer problems > grand visions

The Segment founders (Peter, Ilya, Calvin & Ian) spent years building stuff people didn't want. The sustained failure early on created a product culture of "I will believe it when I see customers loving it"

We spent very little time on vision quests, and most of our time talking to customers

2/ your customers have already figured it out**

In 2014, Peter went on a now-legendary customer roadshow and found a bunch of forward-thinking customers were building ETL jobs to get event data into Redshift. A few months later, we introduced Warehouses so other teams didn't have to build this.

Almost all of our major product launches (Cloud Sources, Functions, Personas, Protocols, Data Lakes) were the productized versions of the things we saw customers (often reluctantly) hacking together. Many of our most advanced customers knew our roadmap long before we did.

3/ building the product is only half the battle**

Great products solve customers problems and are commercially viable. That means that product teams need to think about gross margin, positioning, pricing, how to demo, onboarding, incentives, financial targets for their products.

Personas and Protocols teams spent 6-12 months leading up to + after launch helping enable sales and support. This meant writing sales playbooks, collecting case studies, customer roadshows.

4/ when in doubt, bias to action**

You face a tremendous amount of product and strategy uncertainty early on. There are really only two types of product decisions:

(a) decisions where more data will lead to a materially better outcome

(b) decisions where additional data won't help

go get the data for (a) and make a decision quickly on (b)

5/ talk about the elephants 🐘

A fast-growing product/company is an emotional pendulum between "we might make it" and "we are so effed". It can be uncomfortable to identify a harsh reality (our pricing is broken, we don't have the right team) but Segment's culture helped

Diana Smith consistently and unabashedly made it cool to talk about the elephants in the room early on. A must-read from her here.

6/ great products are created by high-trust, high-context teams

Product, Eng, Design leads are collectively responsible for building high-performing teams. You need to share in the outcomes but everyone brings something different to the product process. There is nothing more powerful than an empowered team that trusts each other to do their best work.

7/ product abstractions matter

There is an invisible force called your "product model" that guides every decision you make. Your Product Model is really hard to change later because everything relies on it, from the names of the tables in your database to your marketing copy. You need to think deeply about your product model from the beginning.

Be deliberate about your product model from the beginning and forward-design where you want to go.

8/ TWMDW

Team work makes the dream work. There is no one person or moment that has defined Segment, but the collective work of hundreds of amazingly talented people. I'm proud of the products we've shipped but 100x more so of the team and friendships.

This was initially published as a tweetstorm here.

There's a typo that runs the Internet.

In 1996, the Computer Scientist Phillip Hamam Barker and Roy Fieldings released RFC1945, which proposed a new header field in the HTTP Protocol. The new field called referer — a misspelling of the word referrer — allowed "the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained". A great addition to the protocol, but ter-ible spelling 😛

75 years later, on every website request that is made, there is now a referer header. Barker later joked that he was trying to get the Oxford English dictionary to adjust their spelling..."since my spelling is used several billion times a minute more than theirs"

SQL queries have been written, databases have been designed, bugs have been introduced...because of how Barker and Fieldings spelled this word.

"In this great future, you can't forget your past"

Developing products is inherently path dependent. History matters. Every product decision you've made determines every product decision you're going to make in the future.

Product-Market Fit is where that initial path is set. It is Decision A. At that point, you could've head in any direction. You could turn around quickly, and head in another direction. But the further you go down a particular trail, the further you have to backtrack. The more people you convince to join you on the trail, the more you have to explain why everyone needs to turn around.

I've found that thinking about your product path dependency is a helpful framework for understanding why your product is the way it is, and how to shape its future. It helps clarify why parts of your product — the product you are building! — stink and are so hard to fix. It clarifies which decisions matter and which do not.

And it helps you understand how and when you can change that path.

Exploring Some Paths

Let's explore a few examples of Product Path Dependency at play...

SMTP Protocol

Most email clients don't let you retract an email once it's been sent. You also can't edit a sent email. Most email clients — from Superhuman to HEY to Gmail — are built on the assumption that a sent email is a sent email.

Products have gotten creative to work around this assumption. Superhuman adds a 10 second wait period to allow you to unsend. If both sender and recipient are using Microsoft Exchange, an email can be "recalled".

But an early decision in 1982 is largely still dictating how much of the world digitally communicates.

Slack is a great example of what can happen when new entrants aren't burdened by past decisions. Rather than using SMTP, slack uses Websockets. When you send a message, the recipients see the message almost immediately. And you can edit, delete, pin and share the messages you're sending.

Once you've used Slack, you wonder why email was so static and immutable. It revisited an assumption, and made it painfully visible.

Instagram

There's been a lot of shade thrown at Instagram for attempting to clone hit features like Stories (Snapchat) and Reels (TikTok). Occasionally these clones will work, in the case of Stories, but most of the time they flop. From NYTimes Tech Reporter Taylor Lorenz:

Instagram started as a simple photo sharing app. Snap photo, add filter, share with friends. Now put yourself in the shoes of the PM responsible for shipping Reels. You're trying to figure out how to fit Reels in alongside Stories, IGTV, Shop, Well-Being Guides, DMs for Brands, Influencers, Advertisers, and a user base in every country around the world.

What to do about product path dependence?

Path dependency is inherent to product development. It is a badge of successfully building something that people want, and an organization that can support it. So if we can't avoid it, what can we do about it?

Early Decisions are Disproportionately Important

There is a paradox of early product decision-making. Early decisions are disproportionately important in that all future decisions will rely on it. Yet they are also the ones that need to be made the fastest and given the least consideration. "Try it out and see what sticks." Until it sticks, and then you are left with that decision for a very long time.

I think there's a way to resolve this tension by making decisions that preserve future optionality. It's somewhat of a hack to avoid making a decision that you will have to unwind in the future.

Let's take a user data model as a simple example. When you have no users, designing your data model is easy. You can change on the fly. As you build more features — like your sign up flow — they are built around the assumptions you made in designing your user model. Are you going to collect birthday? Are you going to ask them to use a company email address? Can they invite friends? As you build upon these early product assumptions, they become harder and riskier to change.

Designing for optionality may take slightly more time, but thinking through some potential options you might want down the line can reduce your path dependence.

• Will Users be part of an Account?

• Will Users need to be Linked via a social graph?

• Will Users need to have multiple Plans?

An option-preserving decision early on can save you months or years of migration work down the line.

Competitors are forging their own paths

Competitors are on a path as well, but it's different from yours. By understanding your competitors path, you can understand what they might do in the future, and what they aren't able to do given their prior decisions. A company geared at large enterprises has likely built a sales team that will be reluctant to lower prices to sell to startups. A company designed to run on-prem will have quarters/years to migrate to the cloud.

New entrants are unburdened by decisions of the the past and can move much faster in many more directions. Every so often, revisit the assumptions and "path" that you are on. If you were to start all over again, how might your product and the org look different? Migrations and re-writes can be painful, but better to do so early than to continue to building on a crumbling foundation.

PMs are the "Product Historians"

PMs can play an important role in understanding the market, organizational, and technology constraints that of the past, that led to the product today. In doing so, you'll be able to revisit past assumptions, avoid making the same mistakes, and build the trust of your team and customers. It's easy to fall into the trap that those who came before made bad decisions. Rarely is that the case. They made the best decision they could with the data and assumptions they were working off of.

By putting yourself in the shoes of those that came before — and really understanding the context — you can make even better decisions going forward.

First, a little about me and my perspective...

• Coming out of school I worked at BigCo (investment firm with 3k+ employees)

• I've been a founder & early employee at startups that have failed to find PMF (Shmob, Viddy)

• I've worked at one startup that has not failed

  • I joined Segment after they raised their Series A. I started on the growth & analytics team before transitioning over to become a Product Manager. During my time we've grown from a small startup to a now sizeable (500 employees) post-Series D company.

• I've coached and invested in a handful startups, of varying degrees of failed & not failed

What's a Startup?

I subscribe to YC Partner Kevin Hale's definition:A startup is company that is designed to grow very quickly.

Startups are distinct from small businesses, large corporations, or side-hustles. One is not better than the other, they just have different goals and pursue different strategies to achieve those goals.

Why does a startup need to grow? There is typically a hypothesis (or set of hypotheses) that the team is looking to validate. To prove or disprove that hypothesis, you need customers to use the product and share their feedback. The best way to know you have built something that people want is that they are ripping your product out of your hands, and using it again and again. That shows up as growth: new subscribers, growing revenue graph, things that look like a hockey stick.

A good example is a new startup I've been using lately to feed my dog, Abby. The Farmer's Dog is a direct-to-consumer dog food company that provides fresh, human-food, vitamin-fortified dog food.

How big is the market for this product? You can run a market analysis, but there's not really a way to know if anyone wants this — and how much they're willing to pay — until you start selling the product. You grow the number of subscribers, and make sure they're not cancelling. Before I got a picky-eater puppy, I would have never believed people would pay a premium for clean dogfood. But now I have week's worth of human-grade dogfood in my freezer.

This definition of startups can (and has) be taken to the extreme of "growth at all costs" — a willingness to throw out ethics and humanness in the name of faster growth. That hasn't been my experience, nor do I think the predominant narrative with startups. But something to watch out for.

Why Work at a Startup?

I'd say the best reason to work at a startup is that, in it's purest form, you get to build a product & company, together.

• build = creating something new (potentially something that has never been down)

• product = something tangible that will hopefully help and delight people

• company = a durable group of people with a shared mission and set of values

• together = you're all on the same lifeboat trying to survive

The last piece — building something together — was something I couldn't fully appreciate before I experienced it. There is an amazing bond that you create with your teammates when the odds are stacked against you and you're working together day-after-day. This was distinctly different from my experiences working at a Big Company, in which there is more zero-sum decision-making (e.g. setting the department budget for the next year) and internally-focused metrics of success (e.g. does your boss think you're doing a good job?).

Why Work at a Startup during a pandemic?

So what's great about startups amid a pandemic?

• Ability to have outsized impact - When you work at a startup, you're generally going to get more responsibility, get more exposure to the inner-workings of a company, learn how to be scrappy and make shit happen. This is especially true in tighter fundraising environments, when you have to do more with less.

• Asymmetric career upside - The beauty of startups on your career is that, from my POV, there is asymmetric upside. That means that the potential for upside outweighs the potential for downside. This doesn't necessarily mean financial upside. But the people you'll meet, the work experiences you'll have, the shot at joining a company that does survive - far outweigh the downside of failure. No one is going to look back at a startup that didn't survive this period and judge you on that failure.

• Depending on your life situation, what motivates you, etc. now can be a good time to focus on "work" - Some great advice I received early on in my career: think about your time as a pie chart. You can spend that time with friends, family, work, hobbies, travel and many other things. The pandemic has changed that pie chart for many people. The time you can spend with friends, family, traveling have compressed. New work opportunity at a smaller company you believe in could be a good way to spend some extra cycles.

Finally, the competitive advantage of most startups is that they can adapt quickly to a changing environment. COVID and the shifting market dynamics means that many businesses have to adapt, and startups can do so relative ease.

What are the downsides to working at a startup during a pandemic?

Most startups are boring and will fail

Most startups are boring. The work at startups is boring. You need to pull a list of prospects to email. You need to answer the same support questions again and again from customers. You need to review contracts, issue refunds, set up your laptop.

On top of that, there's an ever-present risk that all your work will end in failure. A pandemic or recession increases the likelihood that you will run out of money. Companies and consumers are tightening budgets amid uncertainty. After COVID, the fundraising environment has tightened, increasing the risk that your startup will run out of money.

On top of that, there's an ever-present risk that all your work will end in failure. A pandemic or recession increases the likelihood that you will run out of money. Companies and consumers are tightening budgets amid uncertainty. After COVID, the fundraising environment has tightened, increasing the risk that your startup will run out of money.

Startups have less resources invest in adapting to remote work

Just like you need to design your office for people to do their best work, you need to design your remote culture for people to be effective. Startups will typically have less resources to throw at this problem, especially if the startup is shifting from office environment to remote.

How should people adjust their schedules based on the new work-from-home environment? How do you build culture in a remote context? How do you build relationships, trust, and open communication when everyone's on a zoom? There's a lot of effort going into answer these questions. Startups are likely to be the fastest to implement changes, but also have the fewest resources to ensure these changes are working well for all teammates.

Life circumstances, priorities, etc. don't always align with the needs of a startup

Life is not all about work. It's ok to feel sad, confused, anxious — to feel overwhelmed by the political unrest of 2020, the global pandemic, continued racial injustice in America. It's fine to feel like building something new is not the right move.

There are plenty other ways to spend your time and energy. It's easy to buy into the startup-FOMO founder-worshipping buzzy-techcrunch/Forbes BS. You'll be more than ok if you prioritize your personal needs over your career.

How to avoid the downsides of startups?

Startups are inherently risky. But there are a few ways I've found that can reliably mitigate the career risk of working at a startup.

Trust your gut when it comes to the people

You need to be able to trust the people that you work with. If you get a bad feeling someone, catch an offhand comment that makes you think twice, or hear some bad references, there's no idea or business that's worth your time to surround yourself with shitty people.

My experience choosing Segment was all about the people. I had very little understand of the product, the market, etc. But meeting the early team gave me confidence that whatever they were up to was exciting and was a team I wanted to be a part of.

Do you diligence and get other perspectives on the team and company. Twitter, HackerNews, and investors are all great sources to tap into to get independent perspectives on a startup.

Look for a large "margin of safety"

This is a Ben Graham investment principle that's pretty intuitive. Your margin of safety is the difference between the intrinsic value of something and the price you have to pay for it. You can think of this as a built in cushion, or tailwinds. If things don't go exactly as planned, how much does that matter for you or the companies outcome?

Look for startups in which the margin of safety is high. A growing market, stable early customers, new regulations that increase the need for the product.

Opendoor has been marketing their margin of safety as they look to go public. Low interest rates, COVID accelerating the pace of home purchases, shifting needs due to working from home — all of these provide a tailwind for the business that help de-risk your career decision to join.

Try to simulate the day-to-day before you decide to join

If you're considering joining a startup, one amazing feature of startups is that they generally have more work than people. As an outsider and prospective teammate, this presents an amazing opportunity to offer to help before you decide to join. Offer to take on a project, do some independent customer research, join an all-hands meetings.

This will allow you to to understand if you like the work and people before you make any career decisions. And you might be able to help the company out while you learn!

Despite the many options, I always found myself falling back to a spreadsheet — updated manually at the end of every month — to get a complete picture of my finances. Poking around, I learned I wasn't alone. Twitter, Reddit, and HackerNews are awash with the best spreadsheet to start using after you run into the limitations of personal finance apps.

So over the last few weeks I set out to build a more privacy-centric personal finance data platform — called Abstract Capital — that automates data collection and allows me to build financial dashboards in SQL.

And with a few hours of setup, you can to! I've open-sourced the code here and shared the learnings below.

Why Spreadsheets?

There were a few reasons why I always ended up opting for a spreadsheet over these finance apps...

• Incomplete - My goal is to understand how my financial snapshot is evolving across savings, investments, and spending. I need to be able to review and manage all accounts. I found many apps didn't support all the sources of financial activity. These were typically modern or niche tools, like Venmo, Apple Card, and Coinbase.

• Privacy Concerns - To use these apps and build a complete financial snapshot requires providing login credentials (generally username and password) to third-party tools. They mostly use Plaid under the hood to access account info and store additional data about you and your financial snapshot. It feels pretty icky to type in a bank password in to anywhere but you bank's login page. I don't necessarily want a startup with unknown privacy & security controls having a complete view of my finances.

• Shallow Insights - At the end of all that setup, I didn't find the outputs super valuable. Maybe I'd get a cool visualization of my monthly spending, or an alert that I'd spent a lot on a particularly category, but it was often wrong (e.g. I was getting paid back for a large group purchase that wasn't captured) or didn't provide me with the depth of understanding I was craving.

The challenge for these apps is that everyone has a different "financial stack" and use case. Some want to save, some want to forecast and inform large purchase decisions. Some have shared household accounts and some keep them separate. Some pay cash, some rely solely on credit cards, and some pay in Bitcoin. Catering to this diversity is hard!

"Gimme the Data!"

So in August 2020, I set out to prototype my own personal finance data platform. Rather than trying to build the next coolest personal finance app, I wanted to focus on getting myself a copy of my financial data. I called the service Abstract Capital 💸

My requirements for Abstract Capital:

• Privacy-Preserving: Needs to run in my own cloud account, be open-sourced, and provide me with access to the underlying data

• Complete: needs to be able to build a complete snapshot, across all financial data sources

• Flexible: make as few opinions about the data and final analysis as possible

• Cheap: needs to be cheap to run...don't wanna spend $$$ to monitor $

I didn't have to look too far for inspiration. The original premise and environment for Segment (customer data platform) is similar to the personal finance ecosystem of today. Marketing and analytics SaaS is highly-fragmented, with many tools that focus on different use cases, but all rely on the same underlying dataset.

Your financial budgeting, forecasting, monitoring, loan application, and dashboarding apps similarly rely on the same data: how much you've saved, how much you've invested, how much you owe, and how much you've spent.

My goal for Abstract Capital was to automate the extraction and storage of my own financial data, and control which apps and services could access that data.

How Abstract Capital Works

Abstract Capital turns out to be a pretty traditional Extract-Transform-Load (ETL) problem. There are a variety of data sources ("financial accounts") that we need to pull data from, lightly massage it into a standard spec ("transactions", "investments"), and send it along to a central data bus that other apps can read from.

The first (and biggest) problem I ran into was that the financial services I use aren't exactly developer friendly. Bank of America limits their API usage to certified partners and sends you your API credentials via Certified Mail™️. Many of the financial services don't have any public APIs whatsoever. It's a highly regulated industry, providing access to highly-sensitive data, so I don't knock these institutions for not providing a Stripe-level developer experience.

Luckily, Plaid has solved the financial accounts access problem. Using Plaid cut against my goal of making Abstract Capital completely free of any third-party services. Plaid is used by companies like Venmo, Coinbase, and Betterment, so I figured I had enough social proof for my MVP.

Here's how Abstract Capital works...

• Auth with Plaid: Run a Plaid app to authenticate into your accounts

• Sync: A scheduled sync periodically pulls data from your accounts (via Plaid) and writes collection records to topics in pubsub. I set the scheduler to run hourly to start.

• Consumers: Consumers will subscribe to pubsub and write to destinations (e.g. BigQuery, Airtable)

Example: Tracing a Transaction

Let's run through an example run for syncing a transaction. First, we need to create an "Item" (i.e. connect to an account) in Plaid to read credit card transactions. Plaid Link handles all the credential validation and multi-factor auth for us, and provides us an access token we can use to query for our data.

Once we've authenticated, we can see an example Transaction object returned from Plaid (below). It contains all the transaction data (amount, date, merchant) and a join key to an account object. Plaid even enriches it with its own categorization and location of the transaction.

The scheduler kicks off the syncTransactions function (hourly). It queries for the last 30 days of transactions and pushes each transaction into a transactions pubsub topic.

I've set up a Transactions table in BigQuery as an initial Consumer. Our loadTransactions function subscribes to the transactions topic and writes to BigQuery.

Now we can query our credit card transactions in SQL!

select name, date, amount, category 
from transactions  
where name in ('Taco Bell', 'Burger King') 

Getting to the Dashboard

Finally, I connected Mode Analytics and build out an interactive dashboard. I built widgets for Total Monthly Spend, Cumulative Spend, Spend Breakdown by Merchant, and a Weekly Spend by Merchant.

There's also a widget to review Big Purchases and All purchases to scan for anything out of the ordinary.

Cost to Run Abstract Capital

Turns out that due to generous free plans on Google Cloud Platform, Abstract Capital is completely free to run.

• Plaid: Free developer account allows you to link up to you 100 credentials.

• Cloud Functions: Free for 2 million invocations per month

• Google PubSub: Free for the first 10 GB

• BigQuery: Storage is free for the first 10 GB, querying is free for first 1 TB

• Mode: Studio plan allows you to use R, Python, and SQL for free

I wasn't expecting this to be completely free, but most of these services are designed for businesses and much higher volumes of data. We'll take it!

Where to from here?

Overall I've learned a ton from the Abstract Capital prototype. I now own a copy of my financial data, have an up-to-date dashboard I can review, and can write a bit of SQL to dig in to any changes or anomalies. It's empowering. There are additional destinations beyond BigQuery that could be helpful — Airtable, Google Sheets, Twilio (text alerts for large transactions), and TurboTax come to mind.

I'd love to see more companies take a data- and privacy-centric approach to helping consumers navigate their finances. I believe there's room in the FinTech ecosystem for this type of personal finance middleware to power new use cases. There are more products than ever that are providing consumer financial services, so understanding financial picture is becoming ever more difficult to assemble. And need to be able to provide third-party services access data is also growing — imagine being able to provide temporary access to your financial data to apply for a mortgage or try out the latest budgeting app.

Finally, there seems to be an emerging opportunity in helping consumers own their data and run apps in more privacy-preserving ways. Spinning up a BigQuery instance and writing ETL jobs isn't the way most people want to spend their nights and weekends. As deployment models in the enterprise shift from Cloud SaaS to in-VPC ("Cloud Prem Architecture"), there seems to be a need on the horizon for a Consumer Cloud that simplifies cloud offerings and allows consumers to deploy personal apps without ceding their privacy and data.

Thanks to Calvin, Nate, Jason, Osama, Tejas, Alexia, Tim, Niels and JJ for the feedback on this project and blog post.

Squatbot coached us to 10k pushups over the course of the month before ultimately ending in disaster. This is Squatbot's story and the lesson we learned along the way.

Problem: "Leg Day is Cancelled Until Vaccine"

It was hard to see the problem at first. Everything seemed fine in March when shelter-in-place went into effect (excluding the global pandemic, widespread unemployment, and continued racial injustice in America, of course). Stay inside for a few weeks, don't see your friends or family, figure out how to work from home.

It was hard to see the problem at first. Everything seemed fine in March when shelter-in-place went into effect (excluding the global pandemic, widespread unemployment, and continued racial injustice in America, of course). Stay inside for a few weeks, don't see your friends or family, figure out how to work from home.

Paired with the boredom was the isolation. Did I still know how to interact with other humans? Zoom calls with friends became indecipherable from work meetings. Another Pechakucha? Felt like I just finished my last presentation on the History of Cole Slaw.

Finally, the slow decay of our bodies started to catch up with us. Going from a fairly active lifestyle to locked down in a small apartment — eating comfort food 24/7 — had not been good for the waistline. Walking down the stairs to pick up our mail started to feel harder and harder. I was melting into my couch — wasting away, physically and mentally.

MVP: Random Fitness Challenge

Our first attempt to solve these problems was via a group text thread. Fire off a random challenge to your friends and see who bites.

Aha! There was some market demand. People were feeling the same way as I.

This reeked of opportunity.

Squatbot v0: Google Forms & Spreadsheet

That initial text exchange laid the groundwork for Squatbot, a way to physically compete with friends while safely sheltered-in-place.

There were a few key design principles for the first version of Squatbot...

• There needed to be a consistent challenge that seemed hard but sufficiently doable

• That challenge needed to increase in difficulty over time

• We needed a way to track daily progress against the challenge

We started with a daily pushup challenge. Every week, we'd add +10 more pushups to the daily amount. Participants could submit their pushups via a Google Form as they were completed throughout the day.

The form then populated a spreadsheet that tracked our progress:

Squatbot v1: Closing the Peer Pressure Loop

There were two problems we ran into with the first iteration. First, it was pretty annoying to fill out the form. Too much friction to find the link and fill out a few fields.

The second was that the challenge was easy to forget about. There were nights where I'd remember right before bed that I hadn't completed the challenge when I really didn't want to get on to the ground and start doing pushups.

The third was that we were getting burnt out from doing all these pushups.

So we made a few changes in v1...

• Participants can text Squatbot (easier than the form)

• On submission, Squatbot will respond to all participants with the daily tally and the last person who submitted (peer pressure)

• Pushups are replaced with Units of Physical Exertion, a new metric which encompasses body squats, pushups, and pull ups

Under the hood, v1 was powered by Twilio, Google Sheets, and two Zapier Zaps...

• Data Ingestion Zap: Triggered via incoming text message. Parses the submission, looks up the phone number, and submits the form response on your behalf (that then sends it to a Google Sheet)

• Peer Pressure Zap: Triggered on spreadsheet update. Whenever someone submits, this zap pulls the scoreboard and the last submission and sends it to all participants.

It was incredibly motivating. Getting an update that your friends had gotten off the couch to do pushups made us want to do the same. Day after day, set after set.

We were feeling sore. We were feeling healthier.

Squatbot's Fiery Demise 🔥🤖🔥

Over the course of July, Squatbot coached us to 10k cumulative pushups. It temporarily cured some quarantine boredom, and all participants completed the daily challenge for 25 straight days.

However, Squatbot met it's fiery demise on July 23rd, 2020.

After a shall-not-be-named participant (me) failed to complete the daily challenge, the premise of Squatbot soon broke down. Soon the other participants fell off the wagon. Why should we be doing pushups if {Unnamed Participant} is not? Why should I continue now that I've missed a day and our glorious streak has been broken?

The texts stopped rolling in from our fitness robot friend. Squatbot was dead.

Learnings

The challenge of Squatbot was pretty simple. How do you get a group of (remote) people to take an action they all know they should take, but are not doing consistently? How can digital tools create incentive systems to get people to make healthier choices? And maybe have some fun in the process?

There are a few reflections from the rise and fall of Squatbot...

• Codeless can take you far: You don't really need a fancy app or UI or even a website to build a "product". Just some time and a problem you want to solve. Codeless tools like Zapier are powerful and allow you to build prototypes quickly.

• Social Pressure is a powerful force: When it comes to getting users to do something that they don't immediately want to do (pushups), provide positive feedback for good behavior (completing the daily challenge is texted to the group) and disincentivize bad behavior through transparency (a missed day also texted to the group). Fitness apps like Peloton, Strava, and Apple Watch have all harnessed this friendly social pressure to keep people fit.

• Offline-online challenges can work when social trust is high: A question came up pretty early as to how we knew that one of us wasn't cheating. It'd be pretty easy to just text the daily challenge amount to Squatbot without actually doing the Units of Physical Exertion. But the trust among us was high, so it wasn't something we really worried about. I could imagine if this expanded to a group of 5-10+, trust would be lower, suspicions would be higher, and the accountability system would break down faster.

• Prisoner's Dilemma is real: The Prisoner's Dilemma is a paradox where two parties acting in their own self-interest will lead to sub-optimal outcomes. In this case, as long as everyone completed the challenge yesterday, everyone would comply the next day. But once one person defected, the social pressure broke down and everyone defected. Social pressure is fragile. ****It only works when everyone plays by the rules. When one person showcases bad behavior (skipping a day), accountability breaks down and suddenly everyone is bailing.

Thanks to Nate and Jason for helping name, design and participate in this social experiment

There are many ways to influence people and organizations: you can build great relationships, you can be a great salesperson, you can inspire with charismatic presentations. This post outlines another path to influence, which is through the development and distribution of strategy memes.

Strategy Memes Run Your Company

The biologist Richard Dawkins coined the term meme in The Selfish Gene. He defined it as any idea, behavior, or style that spreads person to person within a culture. There's an all-out meme war that is constantly taking place, as ideas take hold, spread, evolve, competing for limited mindshare.

A strategy meme is a short, simple, and memorable perception of reality that spreads throughout an organization. It is often the distillation of complex ideas or data into something that people can easily hold on their head.

Strategy memes are mental shortcuts. They present the soundbite of a much more complex reality. By reducing the cognitive overhead of engaging with the strategy, you allow others to familiarize and engage with the strategy. Strategy memes can align millions of people who have never met, in offices and places around the world. It can become a rallying cry, a clarifying focus, the difference between a project that fails to gain steam and a breakout product.

The strategy meme is like a picture (meme) of your vacation (strategy). The photo is easily shareable and provides a glimpse of the trip. It doesn't replace the actual richness of your experience. No one could look at a picture of Paradise Falls and claim they've been there.

Great Strategy Memes

Strategy memes can be big and small. You are probably familiar with many:7 Friends in 10 Days. Build the Everything Store. Don't be evil. It's the Economy, Stupid.

I've pulled two strategy memes below that are "great" in that they are influential, sticky, and viral. Note that these are all external memes — shared both with the company but also with customers. But many product strategy memes that you'll develop as a PM will be geared towards internal consumers like your sales, support, partners, or leadership.

Blend/"One-Tap Access"

Blend's on a mission to to deliver "one-tap access to the world's financial resources". Knowing very little about Blend, do you have a sense for what that could look like? Have you ever had to fax some form to a financial institution, or sit idly on hold while trying to talk to your bank?

The meme here is the metaphor of one-tap. One-tap is easy. It's fast. It's a familiar motion. It signals a future where the pain of dealing with personal finances is gone.

We have no idea what would be required to make this possible. It says nothing about the fragmentation of the lending market, the lack of APIs that the world's financial resources may have today, or the financial regulations that may stand in the way of one-tap. It paves over all of these into a simple and accessible.

Segment/"What Good is Bad Data?"

Segment is a customer data platform that helps companies understand their users and deliver personalized experiences. It's a technical product that solves a problem for engineering, marketing, and analytics teams. It provides data ingestion, governance, routing, and monitoring tools to make data integration simple. How do you make that accessible and interesting to those who may not be as deep in the problem space, or don't know if they have this problem?

What Good is Bad Data was a marketing campaign that really started with a customer problem. We saw that customers were turning to our product to help clean up messy, untrusted data and confusing, fragile data pipelines. The ability to deliver good data was top of mind for many Segment customers.

What good is bad data is a simple tagline that represents a long-term strategy to deliver a product that allows companies to trust their (formerly untrusted data). It sums up many years of designing tracking plans, specs, schema controls, data monitoring capabilities that many people are too busy to think about.

Stripe/"Increase the GDP of the Internet"

What the heck is the GDP of the internet? Is that possible to measure? And how would one increase it? This strategy meme is great in that it feels accessible, but also makes you want to learn more.

Developing Strategy Memes

What's the recipe for a great strategy meme? Using the above examples, we can extract a few ingredients:

• It's short - this is key. Keep It Stupidly Simple. KISS. People are short on time and have a lot on their minds.

• It captures the essence - there is something insightful and reflective of reality. It makes you lean in.

• It's memorable - It should stick out in someone's mind. Generally done through metaphorical name selection. "we're going to migrate from Mongo to MySQL" v. "RIP Mongo"

• It's accessible - Everyone, regardless of their context, can grasp the meme.

What a strategy meme is not:

• Unfounded marketing: While there's definitely an aspect of marketing, a strategy meme isn't selling something. Ultimately the ability for a strategy meme to be successful — and ultimately realized — is because it's based on a fundamental, complex reality about the world. The meme is the abstraction on that complexity and the vehicle for others to understand.

• An Execution Plan: Note that none of the above get into the how. The ability to execute on the strategy is separate from a communication of that strategy.

How Product Memes Spread

So, you have a new initiative that you're excited about, that the team believes in, but no one else really understands why it's important. What's next?

1. Define the meme: Use the above ingredients to define your meme

2. Create some collateral: A good meme could use some visuals. What's the logo, emoji, diagram, elevator pitch that can help others understand the project and stick out in their minds?

3. Share: Memes spread when others share them. Help others understand the meme. Use it as a psychological short-cut in meetings. Avoid being annoyingly repetitive about it. If others aren't grabbing on to it it's probably not a great strategy meme!

Dark Side of the Meme

Meme's can also work against you if they are untrue, unfounded, or misconstrued. We'll call them Dark Strategy Memes. A few examples you may have experienced:

• Sales: "The product isn't quality, I can't sell this"

• Support: "The product team isn't responsive to the needs of the customers. They're just focused on their roadmap"

• Leadership: "The product isn't moving fast enough...how can we ship faster?"

The same benefit of memes — that they spread quickly, that they create alignment — can be tough to fight if the meme isn't a shortcut for what's really going on.

The best way to fight Dark Memes is to stop the spread as early as possible. Try to understand the sentiment that's leading to this misunderstanding, and then share your perspective, facts, data, narrative as to what's going on.

Takeaways

• As a PM, you're responsible for creating delightful products for your customers. To do that, you need to develop and align the organization around a product strategy. You also need to think about the distribution of that product strategy to get your organization onboard.

• Different parts of the org will engage with your product strategy at different levels. Some will want to understand the full story, some will want to dig into the raw inputs, and most will want a soundbite.

• Make sure you have packaged you product strategy in a way that's accessible to the consumer. One of the fastest ways to spread your ideas is via Strategy Memes, which is a short, memorable snapshot of your product strategy.

• Make sure your Strategy Memes are grounded in reality. Don't be sales-y or gimmick-y.

• Dark Memes will also spread in your org. The best way to combat them is to understand the sentiment behind them, trace the source, and present your facts to stop the spread.

That new product was in its infancy. We had no paying customers. We'd spent most of the prior year developing the product with early beta testers, who were using the product for free.

And here we had a very professional sales dashboard, pretty much zeroed out across the board. A blank canvas, waiting for us and our go-to-market teams to paint something beautiful.

How would we ever turn this dashboard green?

We spent the next 12 months reporting to the team and company on this dashboard. We put the dashboard on TVs in our team pod. Some quarters we'd miss and we'd adjust our product and go-to-market-strategy. Others we'd hit and celebrate. We'd pitch each other new features or marketing campaigns, and bring the conversation back to the expected impact it'd have on our dashboard.

Build Dashboard-First

The best product teams build their dashboards first. That's because the best product managers are maniacally focused, and a dashboard is an easy way to externalize and scale focus across a team or an organization.

Building dashboard-first means that you develop your dashboard before you develop any product or feature. It reorients you from "what are you trying to build" to "what does success mean for my customers, product, and business?"

A dashboard forces you to visualize the outcomes you want your product to have, and have a clear way to measure that impact.

Why Dashboard-First?

A well-designed dashboard forces you to think through the specifics. It forces you to answer key questions...

• How will we measure the impact we're having on our customers? What does success mean for us?

• What data do I need to collect to measure that success?

• How frequently will I need this data?

• What's the best way to visualize our progress?

And while OKRs, PRDs, and Roadmaps can all answer these questions, a dashboard makes the answers to these questions obvious. If you've answered these questions, you have a dashboard the team relies on. If you haven't, you don't.

What goes on your dashboard?

There's been a lot of great thinking on dashboard and metric development, here are some posts I've found helpful...

• Amplitude's North Star Playbook

• Segment's Choosing Metrics that Matter

• Mode's Facebook's Aha Moment is Simpler than you Think

Generally, the approach I've seen work well in developing what goes on a product dashboard...

• Simplicity over science - People can quickly look at the dashboard and understand how it's structured and what it's measuring. Metric precision and complexity often go hand-in-hand, so think hard about where you want to land on this spectrum.

• Correlated with customer value - We can say with some certainty that moving these metrics will lead to success. This does not need to be causal or perfectly correlated, but something that matches intuition and is supported by data. Be wary of anything that just based off intuition or just based off of data.

• Easy to measure - You want something that can be measured easily vs. requires a ton of work to measure. Needing to survey all customers every week may be costly and infeasible. Looking at renewal rates, or customers that canceled their subscription, may be easy.

• Find Leading Indicators- Some part of the dashboard should be focused on your leading indicators of future customer success. A metric that could only be sampled a month before renewal — when you need to know 6 months to change the trajectory — would be a bad metric on this dimension.

How to develop your dashboard?

Here's a pretty simple process you can follow to develop your product dashboard. Depending on the product complexity, tools in your stack, and analytics support, you may be able to get this done alone, or need to work with a data analyst.

1. Draw - First, before writing any SQL or thinking through data sources, draw the dashboard you want. Don't limit yourself to what you think might be possible. Imagine this will be the first email in your inbox every morning iand the new tab screen on your browser...what do you need to know?

2. Prototype - Take your drawing and turn it into a working prototype. Use the analytics tool you're most familiar with (I recommend Amplitude or Mode Analytics).

3. Review with your team - In your next recurring team meeting, review the prototype with your team. Ask for their feedback. What types of questions do they want answered, that the prototype doesn't answer?

4. Schedule - Schedule Dashboard Review as a recurring agenda item at your product team meeting. This creates accountability to incorporate team's feedback from (3) and creates space for the team to review trends and correlate their work with impact.

Tools & Data

There are a few tools that will accelerate your product team's ability to ship and review new dashboards...

• Segment to collect and unify customer data

• Amplitude to build out-of-the-box dashboards

• Redshift, BigQuery, or Snowflake to house your analytics data

• Mode Analytics or Looker to build more advanced, SQL-based dashboards

Examples

Docs

Recently, our success and product teams ran a project to update the Segment documentation.

Segment Docs are often one of the first steps a new customer takes to get started with Segment, so it's important that these . The goals of this initiative were to (a) improve our Docs and (b) collect the data and build the process to continually improve our documentation.

That process begins with collecting user feedback on specific pages that users find helpful/unhelpful, and reviewing that feedback on our Docs dashboard.

Connections

This Connections dashboard gives our team a view across our products, to see how multiple teams were performing across a few standard metrics. I've included the "prototype" below. As you can tell, the hand-drawn prototype can be very rough :)

Necessary, but not sufficient

A great product dashboard doesn't make a great product.

A dashboard is not a product strategy. It's not a "why" that excites and inspires your team. It's also not customer-obsession, or fast iteration cycles, or a high-context and empowered team.

But it does help you — and your team — stay focused on what matters. Build your dashboard first to create that focus.

It's easy to get used to the status quo — to assume the people around you are going to be doing what they're doing for...well, ever. That's obviously not the case, but when you see them in the same role, or the same meeting, day-after-day, it's easy to slip in to that mindset.

There's a small mental shift I've come across that has changed the way I think about working on teams, managing people, and mentoring others.

I've started to assume that the person that I'm working with are on the brink of being the best at what they do. I try to see the futureversion of people.

For people I'm close with, I ask what that means for them. But even for folks that you work with tangentially, you can still see their future versions. If they're a PM/engineer/design, imagine in a few years they'll have built wildly successful products. If they're an marketer or sales, they may be a CMO at a Fortune500 company or end the year as the top sales rep.

Why is this helpful?

• It provides perspective - regardless of the specific situation at hand, it provides me with a broader perspective for who this person might one day become.

• Makes you appreciate their complexity - we're all the protagonist in our own stories. But think about the times where you felt like someone really believed in you or gave you a chance when you didn't think you'd earned it. It's empowering, and those expectations can help people to grow in ways they didn't think were possible.

• It overrides cognitive bias - whether we know it or not, we all have cognitive biases and unspoken power dynamics in the workplace. Assuming people are on the path to be the greatest can help overcome those biases.

• It challenges me to help - what's the path to make this assumption true? what does this person need to get there, and how can I help provide that?

I've been lucky work with a really talented teams, so this assumption is often actually the case. But even if it turns out not to be the case, everyone's better off when you give people the benefit of the doubt.

See the future version of people, and see what you can do to help them get there.

Getting in the Door

I came across Viddy in February 2012. I was working on my own mobile app (what would eventually turn into Shmob, a story for another time). I was working on embedding and synchronizing videos, but couldn't figure out how to stream youtube videos within the app. Viddy seemed to have solved it, so I reached out to the info@ address with our question.

To my surprise, Ken, the cofounder and CTO, responded with a detailed explanation and a few links to put me on the right path. I was pretty blown away by how generous he was with his time to respond to a pretty noob-ish question. It never hurts to ask.

So when I was looking for something to do for the summer, I reached out to Ken to see if he'd be willing to take on an intern. It was a pretty big long-shot. They were a small team, they'd recently raised a large Series B and were growing like crazy. They were also based in Venice, California, and I was not in Venice, California.

But after a call with Ken, I got the greenlight. I'd be working at Viddy for the summer and started making arrangements to move out to LA for my first-ever job in tech.

Doing the Work

I remember showing up for my first day. I'd moved in with my Aunt's apartment in Santa Monica, and she let me borrow this old bike from the '70s that she let me ride to the office in Venice. The sun shining down as I biked between the palm trees on Ocean Avenue, as I headed to my job at a tech startup. Felt like I'd finally made it.

The office was pretty bare bones, a few tables strewn about a nondescript concrete building. My first project was building out the QA/Testing process. I knew very little about QA and Testing Automation, so it was a lot of upfront research. I started with a simple checklist, running through tests manually. Then I started writing Selenium QA scripts to automate it away.

We needed docs for a new public API the team was shipping. I didn't know much about API documentation (or much about APIs). I researched and wrote them. Marketing needed a daily...Viddy... so I'd go out and film something around Venice with the other interns.

I was setting up a pop-up canopy for a Viddy influencer event we were throwing on the beach when I had this realization. Building a company requires work. The Viddy user base was growing at a blistering pace, and the team was sprinting just to keep up with that growth. There was an ever-growing list of things that needed to get done. Docs that needed to be written, events that needed to get thrown, campaigns that needed to be run, bugs that needed to be fixed.

Early-stage companies require work. That work can be incredibly humbling, outside of any job description. There are no roles, just things that are broken that need to be fixed and opportunities that pan out to not be opportunities and those that will change the company's story. You gotta do the work to find out.

Hype ≠ Success

The next few years after my internship would turn out to be pretty rough for Viddy . They ended up getting squeezed by larger social platforms, as Twitter introduced Vine and Instagram added support for videos. Facebook changed its policies to prevent Vidd-ies from going viral. They rebranded, and eventually got acquired.

Startup life is inherently volatile. The swings can be massive, from hitting massive growth targets to successfully closing a round to unexpected upticks in churn or bad press. Viddy experienced it all.

There are a lot of lessons to be taken from Viddy's meteoric rise and dramatic fall. That startups are fragile. That building a social network or b2c app requires a lot of luck. That platform risk can kill a business.

But the biggest one for me is that hype — the buzzy TechCrunch articles, massive fundraising rounds — is very different from building a long-term, sustainable business. Hype can help build momentum, attract employees and interns and investors, and rally the team. But it can't be a replacement for repeatable growth or healthy business fundamentals.

At the time, riding that rusty bike down Santa Monica Blvd, I had no ability to disentangle the two.

Mind the User

One day Nir Eyal — the author of Hooked — came in to the office to run a product brainstorming session with the team.

He walked us through the framework he uses to design products that users will keep coming back to again and again.

First, before the user takes any action, you need a trigger to pull the user in. It could be an email notification, or a link shared on social media, or an app icon on a home screen. Something that alerts the user to the

Then you have an action. A series of steps that a user takes. Open the app.

Then there is a reward. Something that let's the user know they've achieved their goal. This could be other users liking and commenting on their video, or seeing new photos from a distant friend when you log in. Rewards can be variable (unpredictable) or fixed (predictable). Variable rewards max out dopamine levels in our brains as we're unsure if we're going to be rewarded, which increase the likelihood that a habit will be formed.

Finally, there's the investment stage. This is where the user is asked to put in some work. Shoot your own video. Share video. Comment and like. By investing in the habit, the user is more likely to return next time and that investment can be used to improve the loop next time (e.g. stated preferences for what content the user likes to view when they launch the app).

There were two things that I found interesting about this framework. The first was that to be a product builder requires a deep connection with human psychology and how people work. Our products can influence our behavior, both for better (gamifying a workout/diet) or worse (endless scrolls on Instagram).

Second, specific to Viddy (and b2c social networks)...the problem that Viddy was "solving" wasn't super clear. Perhaps it was Boredom, or yearning for Community, or a drive to Create short films. But it's not clear what the internal trigger is that eventually brings users back to their social networks. And if you can't develop one, you won't have very engaged users.

Lessons Learned

So, what did I learn from my summer at Viddy?

• Always Ask - If you have an idea or question, it never hurts to cold reach out to someone who is an expert on the topic. Worst case, they ignore you. But you never know where that question or idea might land you, and people can be extraordinarily generous with their time.

• Building a company takes work - The work required to build a company not always glamorous. There are no "jobs" early on, there's a growing list of TODOs, opportunities, bugs. You gotta do the work.

• Hype ≠ Success - Focus on the fundamentals. Big rounds and TechCrunch features don't tell the full story. Don't get caught up in the things that don't ultimately matter.

• Get into the mind of your users - Building the right thing for your users requires that you not only understand who they are, but what motivates them. Users will return to habit-forming products back again and again. Useless products are an uphill battle to get users to return.