Tom Alterman

The question I love asking every candidate is "tell me the story of the most impactful thing you’ve ever worked on." I like this question for several reasons: * It works for every level of experience. For experienced PMs, I’m expecting to hear about a very important product they worked on. For someone with little to no experience, they can tell me a story about something they worked on that was incredibly hard, impactful and meaningful to them without it needing to be related to product work. * It allows me to get a sense of their storytelling ability. Are they able to structure a story effectively? Are they able to take me on a journey with a clear start, middle and end point? Are they able to do so succinctly? * Lastly, it’s a really helpful way of assessing what they consider impactful and whether they've done something impressive that suggests they'll be a fit for the role. I've heard so many great stories, but one that stands out was for an internship role at my last company: The candidate had not done any product work before, so he told me the story of how he volunteered to help out at a student tech conference. He felt he was bad at public speaking and wanted to watch people do it well. Within a couple of years he was in charge of the largest student conference in Canada and speaking on stage to thousands of people. He told an engaging story that showed me he'd achieved something truly impressive that we wouldn't have talked about if I would have just asked product questions.

At Asana, we don't use leveled job titles to indicate seniority (e.g. Product Manager III or Senior Director of Marketing), but that doesn't mean that we don't have management structures in place. Instead, we use Success Guides for every team that help employees understand what success looks like for each role level at Asana. Another way we demonstrate ownership and growth in role is Areas of Responsibility, key areas of the business that have one designated owner who is responsible. AoRs act as a directory so employees easily can understand who does what, and they offer employees additional ways to stretch and grow outside of a traditional role structure. * As a more junior PM you are working on a well-defined initiative driving the backlog of a single program team or large workstream within a program team. You contribute to the strategy for a program, while the high level elements are largely defined already. You drive work with end-to-end responsibility around execution in a problem space that is fairly well defined. At this stage you are open and curious - your growth mindset is a career accelerant. * As a more senior PM you have a lot of autonomy in running a program team or large workstream within a program team, and are thinking boundarylessly outside your program to drive a seamless customer experience. You may be contributing to multiple backlogs and your work likely touches experiences that are owned by others. You are expected to set the strategy for your program or workstream based on the broader pillar strategy. This strategy must help Asana win. The work that you tackle is difficult, ambitious, ambiguous, and does not have a clear solution from the outset. You coach other PMs informally, and may seek out a more formal mentorship opportunity. Once someone is demonstrating all the competencies at their current level, we then start giving them extra responsibilities. It is only after demonstrating those new competencies consistently do we decide they are ready to be promoted.

When prioritizing your roadmap, focus on the initiatives that will have the biggest impact on your strategy and goals. If you have a retention problem, focus on improving that before worrying about new prospects. And if there is a lot of opportunity to expand with your current customers, focus on that as well. It's generally easier to expand existing accounts than land new ones. It's usually a warning sign if you need to build a very different set of features to meet the needs of prospects vs existing customers. That's usually a sign they are not the same audience. Not a problem in itself but be deliberate if you are pivoting your target audience

My general rule is that you should only share projects with customers that you're at least 80% confident you're going to deliver in the timeframe you indicate. This could be even higher in an B2B SaaS company where customers might buy your product based on that roadmap. I'd therefore be very conservative on what you share publicly. You can share goals or strategies which are higher level that don't promise particular features but indicate the direction that you're going in. I find that usually delivers the impact you're looking for, getting your customers to buy into the vision, without holding you to a set of features you might learn are not the right ones to achieve that vision

The short answer here is Mission -> Vision -> Strategy -> Goals -> Projects/Features. Focus on things that way round and it will be clear what features to prioritize. I'd recommend this fantastic article for a play by play with examples of how to run a great planning process using this structure

The simple answer here is prove that you're approach will make them more money. Here are some more tactical suggestions: * Build trust and credibility with sales leadership. This means showing them that you understand their business goals and priorities, and that you are committed to helping them achieve them. If they see that you're opinions make it easier for them to hit their quotas, they'll trust your judgement. * Frame the conversation in terms of business outcomes. Sales leadership is ultimately interested in driving revenue and growth. When you are discussing roadmap priorities, focus on how your proposals will help them achieve those goals. * Be data-driven in your prioritization decisions. Use data from customer surveys, interviews, and usage analytics to show how your ideas will lead to the business outcomes the fastest

Don't force them to say no, get them to say "Hell Yes!" If the leadership team is not willing to commit to one segment, and you believe that's needed to succeed, then don't make them choose. Get them excited about a specific segment and how it is the fastest path to achieving their goals. Once you have them excited, it will be easier to align them on funding the work that is needed to unlock the opportunities in that segment and pull resources from other projects.

A roadmap is a conclusion to a story that starts with a mission and then continues with a vision, strategy and goals. If you're pivoting, I presume you've already shared why that's happening and the new vision you're pivoting towards. If not, then that's what you need to do first. After that you need to get the strategy and goals updated before roadmap matters. Bring your company along on that journey and you won't need to worry about expectations

We often say that growth at Asana is more like a climbing wall than a ladder—you can choose different paths, get stronger with each foothold, and truly enjoy your journey along the way. That is doubly true for product roles. You get exposure to so many parts of the business that you may realize you want to go explore next. It is also great training for anyone who aspires to be an entrepreneur or CEO of a large company. Andew Anagnost, CEO of Autodesk, advises all aspiring executives at his company to become a product manager at some point in their career. That's because it's the only role where you get to learn how to influence people without having any authority over them. Lastly, it's a great career if you decide you don't want to be a manager or executive. Companies like Asana provide paths where you can achieve great success as an individual contributor. There's a financially rewarding path to becoming one of the world's experts in your chosen area without having to manage others.

The first step in developing a 0-1 product is to deeply immerse yourself in the problem space and understand the users experiencing this problem. This foundational understanding is crucial as it ensures that the product development is user-centered and data-driven. By starting with a thorough grasp of the problem and user needs, you minimize the risk of building something that fails to address genuine demands, maximizing resource efficiency and adaptability in your development process. Here's the approach I take: 1. Gather existing knowledge * Conduct a comprehensive collection of all current knowledge about the problem area. * Organize a collaborative session, such as a FigJam, with key stakeholders to discuss their hopes, perceived risks, and success metrics. 2. Synthesize insights * From the gathered information, craft a clear problem statement, a testable hypothesis, and a prioritized list of assumptions. * Ensure the most critical assumptions are validated first, as their invalidation might negate the need to test lower-priority assumptions. 3. Validate assumptions * Collaborate with your team to design experiments that test these assumptions quickly and cost-effectively. * Aim for a level of confidence in your results that satisfies the team’s criteria for progress. 4. Iteratively learn and adapt * Remain flexible and ready to revise your hypothesis based on new learnings and insights. * Foster a culture of experimentation and quick pivots based on real user feedback and data analysis.