PM work isn’t easy ….Some quick coffee fueled snippets from a product coaching email exchange …

Consider the following …

1. Approach all PM advice with some skepticism. What is the context? What is the product? What is the product stage? Who is the customer?
2. Senior engineers care deeply about the impact of their work, and check out when they don’t sense that impact. Being a cog in a feature-factory is no fun. Address that or risk losing your best
3. Batch your planning and approach it “just in time”. The floors of companies are littered with planning in progress. You can plan 6 months of work in 60 minutes, so why do it ahead of time?
4. Be proactive about giving the team slack to work down debt. Let them know you’re open to that discussion
5. There’s a spectrum of actionable context. More experience = greater ability to act on (and reject) data, context, and details. Junior folks wont have that skill (yet). Point is … respect the need for more context as it gives your best team members the information they need to solve the problem. For junior team members respect that they’re constantly upping their game. Explain how you’re connecting the dots …
6. Leave time to iterate. This is frequently given lip service. “Well, we’ll watch for things and then — while you’re building this new widget — we’ll work it in.” This never (or rarely) happens … and 2 years later, when the context is lost, doesn’t count
7. Cultivate a meaningful ebb and flow. Iterative development can suck the life out of a team. People like challenges and missions
8. Respect the dynamic. Writing production-quality code and designing production-quality user experiences is extremely demanding. There are “passing tests” (usability tests included). As a PM, do you have passing tests?
9. Become a master of driving a shared understanding. But realize that meetings are one of many ways to achieve that (and often the least effective). Visualize things. Record things. Repeat things, in person
10. Creative work requires downtime. What defines productivity in your world (keyboard tapping) doesn’t equal productivity in the UX and Engineering world
11. If the “best ideas win” then make sure that everyone has a fair shot at offering ideas. The reality is that your ideas aren’t always the best ideas. More importantly, cultivate a deep understanding of the problem, or commit to learn more about the problem. The good ideas will flow
12. Quantify the status quo. Too many teams dream up success metrics with no baseline. What is the customer’s current behavior? Later, check to see if your work impacted this behavior
13. “Leftover” work and design/research don’t work well with each other. It’s two different mindsets. Don’t do six 1hr research activities spread over a week while you tie up loose ends. Finish A, and then start B with two days of focused work. That “staggered sprint” thing or “getting ahead of the sprint” … just not a fan. All efficiencies disappear despite it making sense on paper
14. It’s tempting to force convergence (“we need the mockups now!”). The best ideas emerge after an almost uncomfortable level of divergence. Protect this, even if it feels messy
15. You have to be willing to throw code away and start over. As a PM its easy to rationalize otherwise.
16. It’s important to differentiate between linear and non-linear impacts in product development. You can’t scale certain things 2x and expect other things to scale 2x (e.g. # of personas and size of team required to serve those personas) OK. Back to coffee and some doodling.