Context
On 12/12/21, a full year after starting, I got some feedback about Project Management. This jives with some of the coaching that I was getting with Nan toward the tail end of Mode. I think I have a slight allergy/aversion to Project Management. It's not that I believe it to be beneath me, but I think it's more of a thing where I'm not familiar enough with the Meta to be able to morph my style to fit what we have
For example, I think things worked pretty well when we had Emma and Jesse working on RPC together. Things worked less well with Katie—but that was largely because of Katie's split attention, plus the fact that we were branching out into more unknown territory with Coverage Checker. When we started with Devin and Adam, we had to deal with a bunch of unknown unknowns around Sana MD. That, in addition to the positioning that Sheli and Agata and I were doing, pushed Project Management tasks to the backseat
Anyway, I want to increase my learning and knowledge around the Execution sense of the world. Success here looks like:
- Like Intercom, being able to point to a list of things that we shipped
- Like John Cutler, being able to say "of those things that we shipped, here are the things we judged to be 'successes' and 'failures', based on the metrics that we chose"
- One example of this was in RPC, when our first attempt with changing the script didn't do anything, but after implementing 1) redirects by MAs and 2) Hilary's time-based value prop for /chat, the chat rate started climbing immediately
Ideas section
- A couple of use cases jump out
- So the EPD team knows what we are working on in the next 2 weeks
- So the EPD team knows what we are NOT working on in the next 2 weeks (← this is probably the more important thing 🙂)
- A couple of activity categories
- Bug triaging
- Understanding whether a Bug needs to be accepted into the current sprint's queue. Or if it can be relegated until later. This ratio should be low (maybe like 1 out of every 10?)
- Feature Request Parsing
- Backlog grooming
- Make sure that tickets that are next up are clear and have subtasks broken out + estimates
- Questions for us to find our PjM fit:
- Assessing the texture of our necessary quality
- How does our delivery model impact how quickly we can fix bugs? (Alex's proposal: really quickly—we can push/hotfix immediately (to my best understanding), so we don't need to have a rigid QA gate (but we need to have a healthy Bug feedback function))
- How does an unintended behavior impact Users? (Alex's proposal: for Sana MD, since it's new, and our Austin Member base is growing, it's okay for there to be issues at first if it gets us contact with the customer faster. For Sana Care, while the Partnership Day 0 issues can be tough, we're not seeing too many complaints, at least via the tag in ZD, so I don't think it's a burning problem for Members. They just wait a couple of days)
- What hats fall to whom, and how heavy of a focus?
- Re: timelines, how about we just work backwards?
- Let’s start with the baseline that everything in the Sana Action Plan needs to be done by 1/20 (or 1/1). Just start with the number of weeks left and start filling things in
Research
The Only Metric that Matters by Josh Elman
- How many people are really using your Product?
- Not search engines that come in, click on 2-3 pages, and never come back
- You need a metric that specifically answers this. It can be “x people did 3 searches in the past week”. Or “y people visited my site 9 times in the past month”. Or “z people made at least one purchase in the last 90 days.” But whatever it is, it should be a signal that they are using their product in the way you expected and that they use it enough so that you believe they will come back to use it more and more.
- At Twitter, we found that if you visited Twitter at least 7 times in a month, then it was likely you were going to be visiting Twitter in the next month, and the next month, and the next month. And we decided this was enough initially to be "really using it", though of course I think Twitter gets even better when people use Twitter every day or more
Speed as a Habit
- What are the building blocks of speed? When you think about it, all business activity really comes down to two simple things: Making decisions and executing on decisions. Your success depends on your ability to develop speed as a habit in both
- For Making Decisions—err on the side of too fast, and keep the Type 1/Type 2 Decision framework in mind
- For example, the OE Swarm was perceived to be a Two-Way Door: the changes to the Product that we made could be reversed fairly easily. However, that didn't take into account the reversibility of the changes made to the Team, specifically the Designers and Engineers. That was less of a Two-Way Door, and things done during OE Swarm to Engineers' flow (e.g. disruption and thrash) are far less easily reversed
- Speed doesn’t require one leader to make all the calls top-down. The art of good decision making requires that you gather input and perspective from your team, and then push toward a final decision in a way that makes it clear that all voices were heard