Rodrigo Davies

* I get frustrated whenever I hear business outcomes and customer outcomes described as two forces that are in tension, and that it’s necessary to choose between either building a fantastic product or having a fantastic business. It’s certainly possible to have a highly profitable business with a shoddy product, but I believe that the advantage that organizations gain by going that path is short term, and that eventually a poor product experience will erode trust and lead customers to move on to better products. * This is especially common in new product / technology areas, where some companies optimize everything around being the first to launch something in order to capture the so-called first mover advantage and build a moat. Looking back on the last few software innovation cycles, there are many examples of where the second, third or even fourth product to market was the eventual winner, by prioritizing nailing the customer experience and learning from others’ mistakes, over pure speed.

I transitioned from journalism to product management earlier in my career, and although it’s not a straightforward path, it’s actually pretty common for PMs to join tech from other sectors. An Asana PM teammate of mine, Ari Janover, actually has the best articulation of how to make the transition that I’ve ever heard. He says there are three common paths: * The Ninja: Join a small startup as another role and push to own PM work until you become a PM. * The Expert: Apply for roles where the value of your specific knowledge trumps your lack of PM credentials. Think Engineers for technical products or a real estate agent for a real estate tool. * The Hail Mary: Follow the few PM Apprenticeships that don’t require previous experience (learn more about AsanaUp here). I followed the Expert path when starting out, and I’ve seen it work quite well in early-stage companies. One of the biggest challenges in starting in an early-stage company, though, is that you’re often the first or only PM, so although you have lots of things to learn, you may have fewer people to learn from. I spent a lot of time observing and learning from PMs at other companies and building up a group of folks I could exchange ideas and challenges with, and this is a practice I still find incredibly useful today.

For me the biggest differentiator is having a growth mindset. This doesn't just mean they want to make an impact and improve as a PM. For me it comes down to three things: 1. They have a sense of what they know and don't know, and are always eager to learn more. They question their own assumptions. 2. They're humble and curious in trying to figure out what they don't know and leverage the expertise of others. 3. They frequently seek feedback from others and try to challenge themselves, not just to achieve more but to be a better colleague and partner to others.

* One common misconception about b2b product teams is that they should spend most of their time thinking about the buyer (e.g. an executive, IT decision maker) rather than the individuals using the product every day. This misconception arises because in business settings, everyday users sometimes don’t have much choice in the tools they use. However, product teams who focus too much attention on the buyer and not enough on everyday users often end up building products that may get some initial traction, but ultimately become the products teams love to complain about, and in the long run, will stop using. * We focus on making the individual experience of Asana as easy and delightful as possible, so that everyone using the product can see and feel how it’s making work less effortful every day – even if they’re not the person signing the check. * Earning customer love and trust at every level creates a solid foundation for growing your relationship and your business. Moreover, B2B customers increasingly expect and review analytics of how their teams are using products, and if it’s clear that the folks at their organizations are highly engaged with a product and love using it, they’re much more likely to remain customers.

We rate our roadmaps and capacity plans by confidence level – so 6 months out is 70% confidence, beyond that is 50% or more. For choosing the right cadence, I think it makes sense to pay attention to the speed of your iteration cycle, your sales cycle length, and how quickly the space you're in is changing. Hopefully your iteration cycle reflects the other two!

The one attribute that is hardest to coach and most likely to be make-or-break is customer centricity. It's essential that PMs always start with the customer and their needs, and are extremely curious about them. This often comes through in case study-style interviews: some candidates can generate interesting solution ideas without being customer centric, but they will likely then find it hard to explain why they made certain choices over others without a foundation in which customer they're serving and what their needs are. It still surprises me how often folks forget this.

This is obviously very context-specific, but here are some ideas: 30 days: * Understand the business strategy, what stakeholders want and levels of confidence * Understand the customer base, what's known and not known, and sit in on sales calls and UX research (if that's happening). * Understand how the company is shipping product today and where the problems are * Understand what data the company has and what else could be collected * Build high-trust relationships with your peers and leadership stakeholders * Understand what key team members hope for from product management and what they fear * Identify the first high-impact / low-medium effort project or priority that a product manager could accelerate/unblock/deliver, and do it. Model "what a PM does" on a small scale. 60 days: * Meet and build trust with the next layer of stakeholders – if this is e.g. a 20-person startup, this probably means you've talked with every person at the company. * Meet as many of the most important customers that you can. If there isn't a UX research cadence, lead some research to validate the company's top product priorities and bring cross-functional partners along for the ride. * Share what you've learned about where the org is, and the problems you're going to work on, with your stakeholders (and possibly the whole company). Get feedback and enlist collaborators to work with you. 90 days: * Share your recommendations for how the product strategy should evolve or change based on your investigations at 60 days. * Depending on what you found at 30/60 days, you might prioritize: * Establishing a cadence of customer research that you lead but other functions participate in regularly * Defining a product prioritization and development process to help the team ship faster and with higher quality * Regularly analyzing metrics and sharing learnings with the team, and using it to drive decisions

I think this starts with making sure that your design counterparts understand the business strategy and have deep empathy for the customers you're serving. Without those two ingredients, it's hard for anyone to think strategically. As a PM you should invest time in helping design understand the business and customers by sharing what you know – that's a prerequisite – and then regularly invite designers to co-create strategy with you. For instance, share a strategic problem you're struggling to solve, and ask for advice.

It's important to differentiate size of company and stage of company here, although there are some overlaps. The larger a company, the more stakeholders a PM needs to manage, and the more important it is to scale impact by having defined processes that speed up decisions and drive alignment. PMs are usually the folks who design and run these processes, so at a larger company that becomes a greater part of the role. The more mature a company, the more the role of PM is dealing with known problems and metrics, and optimizing the product's performance within those bounds. At an earlier stage company (e.g. pre-product-market fit), there are many more unknowns and more incomplete information, so it's more important for PMs to move quickly and creatively to validate/invalidate hypotheses, and be prepared to pivot their (and the company's) thinking regularly. Of course there are lots of mature companies launching new business lines or trying new strategies, where those early stage PM skills will be essential.

If you're the first PM, building trust is your #1 priority. So I'd start with curiosity about their ideas – where are they getting them from? How are they validating them? What have they learned so far? Where are they getting stuck? It's possible that their ideas are based on some notion of a customer that you can expand and make concrete, by introducing the team to real customers and their needs. If they're not, it's likely the team is running into trouble getting traction for their ideas, and you can find customers to give your team feedback on why the current set of ideas aren't a fit for the problems those customers have. Either way, I would start by exposing your engineers to real customers – through video interviews, or in person, so they can build empathy and understand who they're trying to serve. For example, you might consider inviting engineers to join user research sessions, record the sessions, and share highlights and learnings every week.