I've had the same New Years Resolution for the last three years. Write More. And every year, for the past three years, December would roll around and I would have inevitably...well...not written. There were a series of impediments that always seemed to stand in the way. Not enough time. Not knowing what to write about. Fear of writing uninspiring or boring essays.

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:

Nathan Baschez @nbashaw

When I sent people drafts of my posts for feedback, I never knew what to say if they asked "what kind of feedback would be helpful?" Now I use the "ABCD" framework: - what's Awesome? - what's Boring? - what's Confusing? - what Didn't you believe? (credit to @shl for this!)

March 9th 2020

431 Retweets2,823 Likes

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.

Despite all the care and thought and research we put into product decisions, most decisions don't matter. The Product Requirement Docs, the Product Reviews, the Mocks, the Testing, the Betas, and all the micro-decisions we obsess over along the way.

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.

One of the most helpful mental tricks I've picked up in tackling product challenges is to recursively decompose problems.

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.

I'm incredibly grateful to have spent the last 6 years building products Segment. This week we announced we're being acquired by Twilio for $3.2 billion. Sharing a thread on some of the lessons and principles on how to build products customers love (and the amazing people I learned them from)

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.

HTTyPo

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.