Brittany Cheng

"Poor communication" often refers to a fumbled presentation or incoherent doc. Those are valid! But the hidden part that rarely comes up is how you spread an idea. How good are you at saying the same thing x times in y ways to z people, individually? That's the real grunt work.

The ability to create clarity when there’s no shortage of chaos, opinions, and competing priorities is a rare skill. In any reasonably competent company, this skill alone will help take you quite far, fairly quickly. Concretely, this means creating clarity on the main problems, clarity on the right solutions, and clarity on the action plan & priorities. Very few people can do this well even though most people possess the intelligence necessary to do it. This is because most people in the workplace have been conditioned to add more information, sound more clever, satisfy more stakeholders, and feign more precision & certainty than is possible. Few understand that clarity in a chaotic situation can only emerge from subtraction, never from addition. Clarity comes from communicating what stands out as most important, why it is most important, how it will be achieved, and last but not the least, giving people a way of thinking about why it is okay, even great, that we aren’t doing All The Other Things.

@shreyas @memdotai mem it

Why do some growth stage companies struggle to go from 1 highly successful product to multiple highly successful products? The need for great operations is a common disease in companies that are scaling, especially companies that are going from 1-2 successful products to multiple products that are sold/adopted separately from the core product. Once a company reaches a certain scale, its senior management implicitly begins to view great operations as the most reliable marker of a given team’s (and its leader’s) competence. And they accordingly create incentives for operational excellence, uniformly across all teams. These incentives do tend to produce better results for the teams working on the core product. But these same incentives tend to produce worse results for the teams working on newer products. It is only a really shrewd senior leader who says to an early stage team at a QBR or product review: “it is fine that your team isn’t firing on all cylinders on operations. that is to be expected at this stage. the main & only priority right now is to gain customer insight & creatively build the right things that create differentiation for us in this market.” When senior leaders don’t say this, and when they instead fixate on the operations optics of early stage teams, it makes it nearly impossible for the company to replicate its initial success for its newer products.

@talraviv @lennysan @memdotai mem it

One unfair tactic that @lennysan and I left out of our post—how I use AI for *way more* than drafting documents:

@thenanyu @memdotai mem it

We have pretty simple PRD guidelines — Start with the highest level and get more granular. Start with the widest audience, and get narrower. Start with the stuff that's least likely to change, end with the stuff that's more likely to change as you discover and build. Basic outline is 3 sections 1. Context 2. Usage scenarios 3. Milestones Context What's the marketing statement for this feature? why are we building it now? why do we deserve to win with this feature? Context should not change. This is the fundamental motivation for building the feature, so if it changes, then we need to question what we're doing in the first place. Usage scenarios Present real-life usage narratives that we expect to occur as a result of launching this feature. Anchor this to actual users at an actually moment in time that actually happened. Example: "When Karri was doing the original scoping for his company Linear in May 2019, he visited different startups in San Francisco. He uses [feature X] to track requirements as he learns about them..." Usage scenarios should be pretty stable, but refinement will happen as we start testing early builds. Milestones What are the checkpoints, releases, incremental features, that the team should build, and in what order? What do we need to de-risk up front, what do we leave to the end? Milestones change a lot in scope and number as we build, design, and discover along the way. This is the "living" part of the PRD.

@geoffintech @memdotai mem it

Many hot takes on this one: 1. Data won’t give you the answer in B2B 2. Sales is your best friend, PLG doesn’t scale. Sit next to your best rep. 3. Don’t spend much time debating priorities - eventually it all needs to get built so execute 4. Roadmaps beyond 6 months are inaccurate - so avoid them Love the NYC community thank you for coming out!

@joulee @memdotai mem it

Everyone has an opinion on design. There's always an immediate gut reaction: "Ooh, I love this!" or "Meh." But how do you go beyond that to honing your skills of giving helpful, actionable feedback? Here are the 7 questions I run through when critiquing a product's design 1) What is the user journey to get here? You can’t furnish a room if you don’t know how someone lives. So learn the context: Who is the user? When do they use this product? Why? How did they arrive here, and what's on their mind? Don't critique unless you know this. 2) What do we want users to feel and achieve here? “If you don’t know where you’re going, you’ll end up someplace else.” Let’s understand what a successful outcome looks like before we start lobbing feedback about the design. 3) How important is this page/experience? In a perfect world, we make everything perfect. In the real world, let's spend more collective energy on the stuff that really matters. More eyeballs? More high-stakes? = more thorough inspection of every detail. 4) What is our scope/timeline/team? If speed is critical, let’s get the greatest bang for the least effort. If we have more time and people, then let's remove constraints (#7) and dream bigger. The "best" design differs according to the time/people/money you have. 5) For every proposed design change, am I confident it is better that what currently exists? If no: a) cut it b) iterate on / improve the design c) get more user feedback d) A/B test it 6) What can we remove from this experience and have it work just as well? When faced with a problem, we bias toward adding stuff to solve it rather than removing. So gut check if it's necessary. 7) If we could throw all our constraints away, would we still design it like this? While we can't typically throw all constraints away (see #4), it's still worthwhile to ask because we accept some things as constraints (due to legacy, etc) when they really aren't.

@shreyas @memdotai mem it

“My team has a prioritization problem. Help!“ Product prioritization, a thread: (1/30)

@shreyas @memdotai mem it

As performance review season gets underway in many places now & through Q4, here’s a rough model to help you think about how you are perceived in almost every mid-sized to large company. Your work is generally observed and perceived [0] by others along the following 3 dimensions: 1) Content: this is about the insights & ideas you have, the proposals you make, how you solve problems, the things you ship, the metrics you move in the short-term, the business impact you create in the long-term, etc. 2) Confidence: this is about the image you project as you do your work, do you seem to have things under control, do you seem to be able to tackle tough tasks, how you communicate, do you come across as “leadership material”, are your peers and people above / below in the hierarchy confident in you, etc. 3) Context: this is about your sensibility around your company’s implicit culture, how you adapt your approach to your org’s power structure, that important exec’s quirks & preferences, general biases of important peers & stakeholders, etc. Now, here are some crucial observations to consider as you think about how you’re perceived and how that affects your odds of getting promoted: A) In most companies, if you are extremely good at just 1 of these and average / below average at the other 2, you are going to “get stuck” beyond certain levels (usually Manager / Sr. Manager will be your ceiling). This is unfortunately the cause of a lot persistent frustration for otherwise-talented people who are GREAT at Content, but repeatedly get passed over for promotion to higher levels. They don't understand why this keeps happening. And usually no one explains to them the perception side of things i.e. no one explains that it is usually because they are not projecting as much Confidence as they ought to for the next level and they are not as attuned to the Context of the org & the company [1]. B) To have a chance of getting Director / VP level scope, you must be very good at a minimum of 2 of these and you must not suck at the 3rd one. And btw, this is how you get different types of leaders at the mid / upper management level of a company. e.g. a leader who spikes on Content + Context but not on Confidence is going to have a VERY different style than a leader who spikes on Confidence + Context but not on Content. This observation alone will explain a lot of confusing promotions, where someone seems not competent-enough to be a senior leader, but yet they somehow are the one chosen for the VP job [3]. C) Employees who get promoted to and show longevity at the highest levels (Executive / CEO) in top tier companies tend to be very good at all 3, especially Context. Last but not the least: as with any model, this is by no means a perfect predictor of how things will always work everywhere. But hopefully this helps clarify some perpetually confusing things that happen in our career & in the careers of people around us. ~ Footnotes: [0] If you haven’t already noticed, everything here — Content, Confidence, Context — is about how you are perceived i.e. how Optics plays a role in who gets ahead in midsized & large companies. Now naturally, no company will ever admit or explicitly tell you that this is directionally how things work. They will point to the career ladder and give you some technical reason why the committee’s interpretation was that you did not fulfill one or more of the promo criteria. [1] This is not to say that this is right. IMO it is quite wrong. However, me just saying THIS IS WRONG isn’t going to change the long-held opinions and dogmas of the members of your org’s promo committee in November 2024 or January 2025. [2] In an ideal world, it’s your true Impact & your Execution that should dictate how you get recognized & rewarded. Unfortunately though, in any sufficiently large group of humans the idea of “just do good work and let your work speak for itself” doesn’t work optimally. In good companies it will work for you early on, but even in those companies it will stop working at some point, at some level. When you reach that level, it is fine to decide to opt out of this game (I did that at some point, just before I started this next chapter of my career). But if you do that, be clear on the reasons why you’re doing it so you can remain steadfast while others seem to be playing silly games to get ahead. And even if you want to opt-out at some point, the onus is on you to make sure you’re able to create the life you want to create for yourself from that point forward. [3] This is very likely the most interesting observation in this post for those of you who pay attention to why certain people get promoted / selected for certain senior roles.

@geoffintech @memdotai mem it

Last week, I took the PM team off the grid in the Colorado mountains for 4 days. I figured folks needed a break (I sure did). I never imagined how impactful it would be to bring everyone together. Here are some top sessions to run 👇

@clairevo @memdotai mem it

There are two wildly different pursuits you must execute to build great products: 1. Build what customers want 2. Bet on an unproven future We tend to over complicate or over-wield the former, creating complex mechanisms by which customer feedback is quantified, abstracted, frameworked-away. PMs find the simplest form distasteful (“ugh, why build for one prospect?”) and struggles to implement at scale (hence “no” culture.) Building what customers want is a tactical, commercial minded pursuit with narrower lanes of creativity. This is where speed matters. The best at this are relentlessly practical, with real customer empathy and a big dash of competitiveness. Then there are the big ol bets, which die of human causes: fear, bureaucracy, ego. These are the ideas that get killed in committee, or rot as a crappy MVP, or get called a distraction. It’s extremely hard to get good at big bets. The cheat code? Unreasonable people: Unreasonable people who simply will a future to be true. They say “this is how the world will look, see ya there!” They are OK being wrong (but usually aren’t.) They are, for lack of better word, zealots. These are your founders or your founders-at-heart. The worst thing you can do in a org that has a big thinker is pair them with a team of skeptics—the frameworks and “prove it” and the process. It’s like the first hires at a startup being begrudgingly assigned contractors. You’d never do it. They’d never win. If the first group (build what customers want!) needs execution velocity, the second group (bet on the future) needs vision velocity, where an insight about the market hits an ambitious set of creative thinkers and builds an imagination flywheel that unlocks a Big Idea™️. So think about which of these skills you need. Think about which profile you are. And then leaders: think about how to build human systems around them. You’ll never get great without both models. And your team is where the magic happens. Build thoughtfully! 🚀

@gem_ray @clairevo @thenanyu @memdotai mem it

$$$ slides of my favorite PM talks at config from @clairevo and @thenanyu – both question conventional wisdom of the role itself and how to set up orgs. claire's talk: youtube.com/watch?v=AM0Zzk… nan's talk: youtube.com/watch?v=I4vvBi…

My fave moment about launching is when you start to get all the feedback, good *and* bad. It's incredibly clarifying. All the theoretical things you worried about become real or not real. You know exactly how to make it better. I'm so excited for this moment next week.

@clairevo @memdotai mem it

Was asked recently how I help orgs prioritize—not the frameworks or systems, but how I get buy in from collaborators. My answer? I do sooo much “pre socialization” Basically much of my time spent on incepting everyone around me on themes and levels of investment. “Do you agree on this direction?” And then check, check, and triple check. The biggest mistake I see is the big reveal. Suss out debates early, then have them openly. Invite inspection when change is easier. When “planning” comes all my peers, the team, and my boss should be thinking: oh yeah, I’ve heard this already and agree. I regularly use this basic formula: 📖 Story: did you hear this about that customer? 💡 Theme: this is why I think we need to double down on [this theme] 📄 Plan: so over [time period] I’m gonna ask the team to really sprint on [these projects] 📈 Outcome: I think we’ll be able to [do measurable thing] ❔ Ask: do you agree? <— don’t forget this This is not just an exercise in managing up. These convos should happen at all hands. They should happen in team meetings. They should happen in little hallway convos and slacks. Put the effort up front, have debates early, and create a team that can move fast against shared priorities. And then remember: people change their minds or forget. So do it again 😎

Love love love @vikramadhiman's 3-part advice for being a successful PM: 1. Raise difficult issues without being difficult to work with 2. Bring up important topics without drawing importance to yourself 3. You are in charge of getting the decisions made and not making all of the decisions

@shreyas @memdotai mem it

✨ New resource: a PM Performance Evaluation template (along with a calibration meeting story) Throughout my 15+ years as a PM, I’ve consistently felt that ladder-based PM performance evaluations seem broken, but I couldn’t quite find the words to describe why. Early on in my PM career, I was actually part of the problem — I happily created or co-created elaborate PM ladders in spreadsheets, calling out all sorts of nuances between what “Product Quality focus” looks like at the PM3 level vs. at the Sr. PM level. (looking back, it was a non-trivial amount of nonsense — and having seen several dozens of ladder spreadsheets at this point, I can confidently say this is the case for >90% of such ladder spreadsheets) Then at some point, I saw the light. Here’s how (story time): At some point late in my PM leadership career (this must have been year 12 or year 13), I found myself in a calibration meeting. This is a meeting where a select group of senior PM leaders get together to discuss the performance of the PMs in the org (goal being to rate PMs as fairly as possible, and removing any inconsistencies across individual teams). We were discussing the performance of a PM, let’s call him Bob. Bob did not report to me, but I had seen Bob’s work very closely (he worked closely with a couple of PMs who reported to me). Bob had very strong peer reviews, manager review, and I personally thought that Bob was a very strong PM. But the discussion in the calibration meeting (which is largely driven by the ladder spreadsheet) was turning in a direction I wasn’t expecting. Someone in the room said “well, I can see all the strong reviews and the execution, but I am concerned Bob hasn’t shown any strategic insight over the past 6 months [provides more evidence to support the comment]. So accordingly to our ladder, they don’t meet the requirements for an Exceeds or Strongly Exceeds rating”. Some other meeting participants dutifully chimed in with a +1 to that comment. The room was almost ready to move on to the next PM, when someone else in the room asked: “well, but did Bob do what’s right for his product and users, what he was required to do in this situation?”. That was a wonderful question and so I chimed in with my view: “Bob did everything right, in my opinion. Yes, Bob did not check the box in the career ladder for what we expect on strategic insight, but he did what’s right for the company, so it would not make sense for us to penalize him for that just because he didn’t check that one box over the past 6 months”. Bob eventually got a better rating than the group was initially leaning towards and I think Bob is still at that company, so it all worked out I guess. But, this calibration conversation prompted me to really re-think how we do PM performance evaluations. That then led me to develop the Insight-Execution-Impact framework for PM Performance Evaluations, which you can see below: I then used this framework informally to guide performance conversations and performance feedback for PMs on my team at Stripe — and I have also shared this with a dozen founders who’ve adapted it for their own performance evaluations as they have established more formal performance systems at their startups. And now, you can access this framework as an easy to update & copy @coda_hq doc here: @shreyas/evaluating-pm-performance" target="_blank" rel="nofollow noopener">coda.io/@shreyas/evalu… This template makes it very easy to create greater clarity & transparency on how your performance is being evaluated as a PM. As you select the stage of the product the PM is working on, this doc updates the weights you’d assign to Insight, Execution, and Impact (e.g. you cannot expect regular business impact metrics to get moved in 3 months for an early Explore stage product) And then this table is where the PM can clearly see how they did along the dimensions of Insight, Execution, and Impact during the evaluation period, along with the weighted contribution of each, and written feedback from the manager with more details. How to use this template as a manager? In a small company that hasn’t yet created the standard mess of elaborate spreadsheet-based career ladders, you might consider adopting this template as your standard way of evaluating and communication PM performance (and you can marry it with other sane frameworks such as PSHE by @shishirmehrotra to decide when to promote a given PM to the next level e.g. GPM vs. Director vs. VP). In a larger company that already has a lot of legacy, habits, and tools around career ladders & perf, you might not be able to wholesale replace your existing system & tools like Workday. That is fine. If this framework resonates with you, I’d still recommend that you use it to actually have meaningful conversations with your team members around planning what to expect over the next 3 / 6 / 9 months and also to provide more meaningful context on their performance & rating. When I was at Stripe, we used Workday as our performance review tool, but I first wrote the feedback in the form of Insight - Execution - Impact (privately) and then pasted the relevant parts of my write-up into Workday. So that’s it from me. Here’s the template once again (you can easily copy it and play around with it [0]): @shreyas/evaluating-pm-performance" target="_blank" rel="nofollow noopener">coda.io/@shreyas/evalu… 📈 [0] And if you want more of your colleagues to see the light, there’s even a video in that Coda doc, in which I explain the problem and the core framework in more detail.

in every company there's at least 4 different manually updated spreadsheets of what people are working on, all slightly outdated in a different way

@itspatmorgan @memdotai mem it

As Karri notes, B2B design is quite different from B2C, but it doesn’t get much publicity. I learned a lot by designing 3 separate 9-10-figure cybersecurity startups in the last 8 years. A few thoughts: Managing multi-persona dynamics The distinction between buyer and user is a big one. For me, that meant designing mostly for the security engineer (the user) but delivering enough value to the Chief InfoSec Officer (the buyer) for them to see it was worth spending hundreds of thousands or millions of dollars per year on our product. In some cases, other third-party employees could torpedo the sales process too (like if a CTO or Chief Architect decided they didn't want to accommodate our architecture). Lack of quantitative scale I never had the user scale to get quantitative results fast enough to routinely inform design decisions. This in turn prioritized a combo of qualitative research and craft to make design decisions. TBH a good environment for designers to flex their skills. Different "voice of the customer" Design wasn’t the sole “voice of the customer.” We had entire teams in professional services and customer success who were in constant contact with users and whose job it was to represent their needs. This shifted my focus to be more on leaning into those relationships, interpreting the constant flow of feedback, and synthesizing it into smarter design choices. High-stakes design changes The stakes of making changes were very high. If we made a poor design decision that resulted in a major error it could take down our customer’s systems (and the other businesses that depended on that company’s services). This meant we needed to “measure a hundred times to cut once” and be very deliberate in our prototyping and rollout process. Publishing more thoughts on enterprise design this weekend on betterbydesign.cc It’s an area ripe for design disruption with the right culture shifts.

@karrisaarinen @linear @lil_dill @memdotai mem it

Last night, we at @linear hosted a design leadership event. We invited about ~25 design leaders from top companies to join @lil_dill and me to discuss b2b design, quality, and craft. There were many good comments and questions that came out of this. I'll try to see if I can share them somehow, but first, I wanted to share why I was interested to do this event: I often hear design talked about generally or in the abstract, but I haven’t really seen people highlight how design and practices differ between b2b vs b2c design. Traditionally, design hasn’t been prioritized in the enterprise, but I believe design can be much more important there than on the consumer side. Enterprise or professional software often provides tools or solutions to someone to create or generally do their job or do it better. The bar for the solution can be very high, and the user is very discerning of that solution. If the design tool the designer uses isn’t that good, the quality isn’t there, and it’s very apparent. Since people are relying on the service to do their job or run their business, the stakes and need for reliability are also higher. If you constantly A/B test random things, it can cause disruption to the workflow, and therefore in the operations of the company. Design choices and changes should be considered and validated with beta programs. Almost all companies serving other companies are in retention and usually also in net retention business. Ideally, you keep your customer forever, and you want the account to grow over time so their net dollar retention goes over 100% year after year. Design can have a huge impact on building loyalty. One main reason companies churn from products is when the product quality and design speed drop. Customers get frustrated, so they start looking for other options. Good design has the power to do the opposite. If you consistently delight the customer, you build up that loyalty and trust. I think landing customers can be a finicky process. There might be many people in the process trying to evaluate your product against some other product. Usually, customers cannot inspect your code, or even fully grasp the product strategy, but one thing they can do is experience the product experience. Good design (and obviously the quality of the product execution) can really elevate that experience and be the thing that gets the customer excited about your tool. But it's not all roses. The reason why design is hasn't been traditionally prioritized in the enterprise is that enterprise software has buyers and users. The buyers often don't use the product or even try it. If you work in a company that gives you janky tools, it's probably because the buyers had other goals and the product experience inconsequential to those goals. But I don't this is practice is going to sustain. The pressure and demand for well working and well designed enterprise tools will continue to rise and eventually buyers will realize why they are there – to elevate their teams with the best tools available.