In JC’s Newsletter, I share the articles, documentaries, and books I enjoyed the most in the last week, with some comments on how we relate to them at Alan. I do not endorse all the articles I share, they are up for debate.
I’m doing it because a) I love reading, it is the way that I get most of my ideas, b) I’m already sharing those ideas with my team, and c) I would love to get your perspective on those.
What do we think about product reviews? How to make them work in our async culture?
The importance for PMs to share the why and to storytell well.
We have design crits and product reviews.
Design crits are intended to be very generative, and are explicitly not about making decisions. Designers share a file (often on FigJam), and we spend 10 minutes headsdown silently leaving stickies and comments to give feedback on the designs before discussing live.
Product reviews are more about making decisions and debating directions.
We have different kinds: ones where we’re trying to align on the problem or ones where we’re trying to align on the solution.
One thing I encourage for both is to first present the “option space”—it’s really powerful to have a framework that maps all possible solutions or problems and use that as a device to discuss high-level tradeoffs or philosophical differences.
My favorite is adding the alignment widget, which lets people share/vote on their sentiments toward specific decisions; I find this so much more powerful than allowing the loudest people in the room to dictate the outcome!
➡️ Do you need consensus to make good decisions and creative ones?
Crits are a central part of our design culture at Figma.
We have five standing slots each week, and attendance increases in size with each session over the week (e.g. Tuesdays are for tech pillars, Thursdays for Editor and Non-Editor teams, and Fridays are for all of design).
Designers have control over booking them and inviting any additional teammates (beyond the pillars or teams already in attendance). We send out an automated reminder each week in Slack for sign-ups.
For the larger crits, we also welcome guest “observers” from across the company. We believe it’s important for everyone to see how designers share ideas and offer feedback on projects. We encourage every employee to attend at least one crit per year, regardless of their role or position
Our crits are fairly structured, following a similar format and led by the presenting designer. Typically we get to two topics per meeting, with a rough agenda of:
~10-15 minutes of presenting (we use Spotlight in FigJam, and attendees are welcome to comment while someone is presenting)
~5 minutes of lingering questions
~5 minutes of silent writing and commenting on the file
We find that this format gives presenters a greater breadth of feedback, while offering a few different entry points for attendees. For more about crits, our Vice President of Design Noah Levin wrote about our process here.
It’s my belief that PMs are responsible for the “why.”
Ideas of what we build come from anywhere (including our community!), and the “how” often comes from design and engineering.
But I’m pretty insistent that PMs make it crystal clear why we’re solving a particular problem and why it’s important over anything else we could do.
As such, when the why isn’t clear, I really push my PMs to invest in internal storytelling.
Aside from this, what I think is unique about our product team is our proximity to customers. We spend a lot of time with them, and crucially, we do our best to maintain a close relationship with the community.
The most important thing is that customers see value in what we build and deliver.
Ship something you’d be proud of putting your name on it.
Good idea of the monthly design reviews.
Interesting stages of product reviews.
The Product team’s motto is “Deliver customer value faster with high quality.” The most important thing is that customers see value in what we build and deliver. It’s what we want the product teams to focus on.
The “Mona Lisa principle”—simply put, everything we ship should be like a Mona Lisa painting, something we’d be proud of putting our name on. When you look at a painting, you can easily say that something is a masterpiece and something is definitely not; the same is true with the product.
The Design team built the monthly design reviews. Every month, they review everything that was shipped and say what is high-quality or not. You know how a picture is worth a thousand words—similarly, real examples of high quality are a lot more powerful, and simple at the same time.
Product reviews can focus on different stages of the product development lifecycle:
P-Strat: long-term strategy and vision
P0: the opportunity and problem that we want to pursue
P1: the proposed solution
P2: what we launched and how it’s performing
Each stage has a defined template outlining the type of information the team should bring (e.g. for P0 product alignment stage).
Do we have explicit crunchtime? (crunchtime refers to a timeboxed period when most members of a team do extra hours to get an important project done.)
Interesting lesson on tech debt being not a concern at wartime start-ups
The experience of Uber:
At first I thought Uberʼs Rider app rewrite was a one-off crunchtime event. However, it wasnʼt: other projects felt equally high pressure and we operated on the understanding that we needed to move fast, or else… Or else, what? Looking back, most deadlines were artificial; set by the CEO without any external reason to hit it. Still, we never questioned them and all marched to the leadership's tune.
Large parts of Uber operated like it was wartime for lengthy periods.
When to be in peacetime vs. war-time:
“Peacetime in business means those times when a company has a large advantage vs. the competition in its core market, and its market is growing.
In times of peace, the company can focus on expanding the market and reinforcing the companyʼs strengths.
In wartime, a company is fending off an imminent existential threat.
Such a threat can come from a wide range of sources including competition, dramatic macroeconomic change, market change, supply chain change, and so forth.
The great wartime CEO Andy Grove marvelously describes the forces that can take a company from peacetime to wartime in his book, Only The Paranoid Survive.”
Ben Horrowitz example:
In the same article, Ben gave several examples of the differences in leadership styles, writing:
Peacetime CEO knows that proper protocol leads to winning. Wartime CEO violates protocol in order to win.
Peacetime CEO focuses on the big picture and empowers her people to make detailed decisions. Wartime CEO cares about a speck of dust on a gnatʼs ass if it interferes with the prime directive.
Peacetime CEO thinks of the competition as other ships in a big ocean that may never engage. Wartime CEO thinks the competition is sneaking into her house and trying to kidnap her children.
Peacetime CEO aims to expand the market. Wartime CEO aims to win the market.
Peacetime CEO strives to tolerate deviations from the plan when coupled with effort and creativity. Wartime CEO is completely intolerant.
Peacetime CEO strives for broad-based buy-in. Wartime CEO neither indulges consensus building nor tolerates disagreements.
Peacetime CEO trains her employees to ensure satisfaction and career development. Wartime CEO trains her employees so they donʼt get their asses shot off in the battle.
➡️ Agreed
Wartime vs. peactime:
➡️ Crush alignment, work fast to deliver product.
Crunchtime:
Crunchtime refers to a timeboxed period when most members of a team do extra hours to get an important project done.
This usually means working overtime and involves freeing up time by canceling meetings, non-essential work, and projects.
Whatʼs true of any crunchtime is that itʼs stressful, but ends as soon as the project completes.
However, extended crunch periods are common at wartime orgs, when the scope cannot be cut on the basis it might cost customers or market share, or when no other teams can help as theyʼre already stretched.
Tech debt:
Most peacetime tech companies tend to allocate a healthy part of engineering work to paying off tech and architecture debt, usually 10-30% of the engineering teamʼs time. Also, engineers are rarely overworked during “peacetime,” so can address tech debt by putting in a few more hours, without impacting their existing work.
Tech debt can – and does! – accumulate at companies in wartime mode. Getting things done quickly is more important than finding the best solution, including for maintenance. This means tech debt snowballs and thereʼs usually very little capacity to pay it off.
Over time, it should become unbearable and force the company to grind to halt, unable to develop new features quickly. Right? Actually, this usually doesnʼt happen. From personal experience and talking with engineers at startups whoʼve only known a wartime mode, tech debt is not a top concern.
So why do many companies in lengthy wartime phases not suffer badly with “tech debt”? Uber was a case where a “wartime” focus might have been expected to seriously impede it from moving fast. And yet, move fast the company did. Here are some counterintuitive reasons why a wartime setting neednʼt be bad for tech debt:
Constraints foster creativity in cutting tech debt. Itʼs true that during crunchtime, thereʼs pressure to ship and tech debt is accepted with the intent of paying it off later. During long periods of wartime, engineers know they need to maintain what they build and that there isnʼt dedicated time for paying off tech debt. Turns out, capable engineers then make pragmatic – often elegant – decisions which reduce future tech debt.
Improving maintainability becomes table stakes to not burn out, as an engineer.
During an extended wartime, it becomes essential to be able to explain to other engineers what the real problem with systems is, and what a fix would look like. Why is this essential? By verbalizing the problem and solution, you can get their support to act on it, quickly.
Rewriting systems is easier to justify during wartime than in peacetime.
But during wartime, decisions like this can be made at the discretion of a team, or an engineer, if progress is fast. Engineering teams at wartime startups frequently build new systems when their existing ones accumulate too much debt, or become less reliable.
Microservices can be a more natural fit in a wartime environment. Thereʼs already a pull to build new services, so why not make it easy? This is the reasoning process many experienced engineers go through, so it makes sense to allow teams to build new services quickly, and then operate those services.
Really important about building your own mental model about what are the problems of customers & members, and being creative with solutions.
I saw this problem at Stripe as well. Patrick would always ask PMs if they’ve talked to users. PMs would reply yes.
But in many cases they were simply summarizing what the users told them, without actually understanding what the users really needed.
These products struggled to win (and are still struggling), despite having Stripe’s brand, resources, and distribution.
These PMs were not Craftspeople (they were usually Operators).
So unlike Patrick, who could figure out the right answer after talking to users, talking to users was a necessary but not sufficient condition for these PMs to decide what to build (both macro and micro).
The importance of good taste when building products (don’t try to measure the unmeasurable)
There is a popular Apple Pie Position, which goes: “If you don’t measure it, you cannot improve it” This belief is often harmful on early-stage teams.
1) You need leaders who have good taste. Without good taste, everything becomes an exercise to “prove it conclusively”, which slows teams down
5) In all cases, understand that there is a difference between *evaluating* how something is going and *measuring* how it is going. In some cases, you can simply evaluate without performing crazy contortions to measure. Of course, such evaluation requires good taste and judement
It’s already over! Please share JC’s Newsletter with your friends, and subscribe 👇
Let’s talk about this together on LinkedIn or on Twitter. Have a good week!
