Aleks Bass

Our product development lifecycle process looks very similar to a double diamond design process but with an adapted approach for our organization. While there are best practices for a product development processes, I've found that there is a decent amount of adaptation and adjustment that needs to happen to customize an approach for the needs of the organization. I've not seen 2 product lifecycles that are the same. At a minimum, a product development process should help reduce friction for the R&D teams, create clarity around what we need to know before we invest, and insight into the variables that influence those decisions. The most mature and refined PDLC programs also create consistant expectations of each role that participated in the product development process, sets criteria for high quality output, and provides clarity on what to do next through each stage. This is extremely benefitial when you think about onboarding new PMs to the team, as well as supporting the growth of PMs new to the role. Depending on the needs and maturity of your organization, you can chooste to implement a light version of this process that focuses solely on alignment and rescource allocation, or lean more into a more detailed process that provides more clarity on activities you expect the teams to execture for each stage. A good process provides time and space for the team to engage in activities focused on discovery, exploration, and time in a particular problem space. In this stage. you should avoid solutioning at all costs. There should be a stage for concept exploration, and I strongly encourage my teams to explore more than 1 concept. Sometimes the first concept we surface is not the best for the job, but inertia and time constraints prevent us from exploring more. I recommend my teams take the time, because it saves us on the rework later. Once a concept has been validated, there should be a stage that allows you to define the high level requirements and start thinking about an experience that would make it as easy as possible for customers to realize value from your chosen solution for the problem space. For me, customer validation of the specific execution is critical, because we are very rescource constraigned on the engineering side. If I can prevent rolling out soemthing that needs major rework, I will. Some organizations are more constraigned on the research or PM side in which case you may use the experience itself for validation. There are many types of product development lifecycles, and you should choose an execution that solves the most prevalent R&D problems your organization is facing. 

There are several stakeholders that have input into our roadmap, a few main partners and collaborators are listed below: * Other Product & Design Teams * Sales/CS teams * Marketing & Growth * Research * And more… Most cross-functional partners just want to be heard and want to understand whether their requests will be addressed or not. This is why transparency is a key element in all 3 of the following tips to help you maintain the balance between influence and control: 1. Give your cross-functional partners an acceptable avenue to advocate for customer requests and surface themes they are hearing from the market. We have a very specific process for capturing requests. All requests get routed through a feature request or feature feedback form that is centralized for our product team to analyze and address. We look at the data coming through those channels monthly and roll up the insights quarterly. The expectation is set that we will evaluate all requests but that there is no commitment to addressing any specific requests. An important aside is - As a product leader, be grateful for the feedback that you receive, there are many organizations that aren’t benefiting from the insights you are getting straight from the customer-facing teams. 2. Help your cross-functional teams feel heard; be transparent about realistic outcomes they can expect. In all of the organizations I’ve had the privilege of working with, the friction between cross-functional product requests and roadmap prioritization was anchored on a misunderstanding of the product management function. Helping your cross-functional partners understand your process, their input’s role in it, and the outcomes that result should help alleviate some of the pressure to “just put it in the roadmap”. 3. Close the loop - even internally. My team has a quarterly meeting with our cross-functional partners to give them an update on 1) the requests we’ve received, 2) which items have been delivered, 3) which items are in progress, 4) what our current expectations of delivery are, and 5) which ones we’ve recently received. We also address the items they have requested that we will not be delivering and do our best to explain why (e.g. not aligned to our current strategy, not a point of differentiation, we don’t have resource capacity for another large initiative right now, etc). This meeting alone has had an incredible impact on our ability to keep our team aligned with our cross-functional partners.

There is an interesting tension here between looking at problem spaces from a variety of angles to make sure you have a sound and differentiated strategy that is worth pursuing and inciting decision paralysis by having too many individuals involved in the process. And the truth is, it depends on the project. I’ll give you a couple of examples for how we have tried to simplify the investment of time and talent for this particular challenge, but it may not work for all organizations. The approaches we take have to be at least a little malleable for the organization or adoption and usefulness suffer. I’ve worked in a few organizations where the investment in exploring a problem space (without a confirmation that investment in this problem was guaranteed for the company) took too much time from key product development functions and even some business and support functions. It felt quite similar to the sensation of dating but never really knowing if this is “going anywhere”. That amount of uncertainty caused a ton of friction in our teams. Some people responded by avoiding the problem space until it was “clear” that it’s prioritized. Some people were so bought in that they went above and beyond to try to convince the organization that it was worth the investment but without crucial data or participation from important stakeholders, so the recommendation never reached its full potential. By the time a decision actually was made (if ever), many people on the team were so frustrated with the project and the level of uncertainty around it, that it took twice as long as it normally would to communicate that it was now prioritized and we were ready to start work on it. This causes a pretty major time delay in some areas. An all around a frustrating experience for everyone that resulted in sub optimal outcomes. Hopefully this example isn’t sounding too familiar to you, but it’s what motivated me to try to leverage our product development lifecycle to create better clarity around who is involved in the exploration of a problem space, what does the exploration of a problem space mean (what activities or information is needed to make a decision), and a ceremony to close the gap of alignment and make a decision on whether it’s something we plan to pursue or not. The first step for me was finding a way to harness the power of the organization at scale for sourcing ideas around problem spaces to explore. We therefore created an intake process that allows anyone in our organization to submit ideas for consideration. They can also tag a customer in the request if it was a customer request, etc. This allows us to get a head start on assessing the opportunity or impact of a particular problem space. The second step was to simplify the information needed to make a decision, and provide clarity and a touchpoint to the team around this stage in the process. I shouldn’t need a full development estimate and wireframes to decide whether or not I want to invest in something that isn’t likely to drive the financial or experiential outcomes our team is targeting. So the sooner you can say no to the project you don’t think will make an impact on your product or business, the less spinning your teams will do and the more clarity they will have on executing on the right things. Here is an example of what our teams will source answers for before a problem space is approved for further work: Our teams (PM, PMM, Design, & Research) answer the following: * Alignment with our strategy - what part of our strategy does it support? (Growth, Retention, Competitive Differentiation, Improved Customer Experience, etc). * Current capabilities - how close are we to having a solve for this space? Is there a workaround? * Opportunity - How painful is this problem and what is the impact to customers if it were to be solved? How will investing in it benefit the company? * Success Metrics - what metrics would be expect to move? On our teams the PM is responsible for the deliverable, but the other team members are contributors with critical points of view and data to contribute. There are potentially many other sources of support within the broader organization that are included depending on the problem space and their unique purview, but we try to keep the teams small so that we don’t slow down the process. Once the team answers these questions, they present their opportunity assessment to our product leadership team who then decides if this is a problem space we will invest in, and provides support via resource allocation, prioritization, etc. Of course these questions are not enough to fully answer the question - Is this worth investing in? Things like capacity, level of effort, which solution we choose, and many more can have an impact on whether something is worth investing in or not. But this allows us to structure a meaningful touchpoint in the flow of the process that can remove problems we likely won’t invest in early enough so they don’t create unnecessary drag on the team. We have this same opportunity further down the line when it’s appropriate to look at the recommended solution, or the investment in development. In many ways this process is like a funnel. There are stages and things you can remove early because they just don’t make sense, but there should be more opportunities to change your mind sprinkled thought the process as you get closer to development.

The 30/60/90 plan is very helpful for anyone coming into a new role, but specifically for PMs there is a simpler way to break it down. This won't libe up perfectly, but I'd think of it as a product managment process... your first 30 days are for discovery. You are talking to people learning about the company, the customers, the product, the processes, everything. You should be analyzing and synthesizing themes and coming up with hypotheses for what you think is needed, and that will be different at each company. For example, sometimes I've come in and the strategy was sound, the ideas were sound, but the way it was being being communicated to customers and internally didn't make sense. Other times I've come in and the idea itself was suspect. I would approach those challenges differently, but I first need to understand what I am dealing with and then I can figure out how to approach it. That's what your first 30 days are for. The 30-60 day stage is for concepting. At this point you should have identified some challenges and opportunities and have some ideas or hypotheses on how to have an impact. You will have some ideas that are great, and some that others have tried and failed implementing. It is helpful to uncover which is which quickly. In days 30-60, you should start sharing these opportunities to gauge support and interest from xfunctional groups you will rely on for execution. Pick things that are best positioned for success. For example, don't pick the project everyone is against as your first one. Maybe save that for later when you have more momentum behind you. Days 60-90 are for execution. This is where you should start executing on the opportunities you've discovered. Dont forget to promote the changes you are making, but in an authentic way. If no one knows about the things you are working on, did you even do the work? Thats extreme, but you get the point. Make sure people know about the work you are doing and the impact you are having. One more tip: The biggest mistake I see people make on their 30/60/90 day plans is to do them in secret. At the very beginning of your tenure at the company, you want to align on your plans with your manager. This will be the fastest way to detect whether your expectations are aligned or if there is a disconnect between what you think your should be doing vs what your manager thinks you should be doing. 

My objectives when meeting new stakeholders are centered around finding out more about them as a person and how they like to work, understanding their objectives, and getting feedback from them about what their experience with my team, function, and the broader organization has been. Here are some details about why and how I dig into these topics: * Personal - I find it’s easier to build relationships and avoid some negative behaviors and experiences with people at work when you put in the effort to get to know more about their life outside of work. I try to get a sense of where they live, what they do on the weekends, etc. In every case, we either find something we both love and are passionate about, or find some very comical differences, both of which give each of us a better sense of the other person. This is helpful in building empathy between you and your stakeholders. It’s much harder to assume negative intent or to be rude to people you have bonded with over things like the best local coffee shops in a favorite neighborhood for instance, than ones where your only experiences are work-related. * Goals & Objectives - The next area I focus on is understanding their objectives and goals. To put a finer point on it, I want to understand their objectives and goals for themselves and their team, and what they need to be successful. The stakeholders of a healthy organization generally want the same outcome (more revenue, better customer experience, etc), but they differ on the prioritization of the goals and/or the method for reaching that goal. I ask questions and try to uncover details that will allow me to link my goals and theirs in any way. I then look for opportunities for my role and skillset to contribute positively to my stakeholder’s goals, and I brainstorm some of these opportunities with them. The shocking thing is how many people are taken off guard by this approach. So rarely are stakeholder meetings voluntarily helpful that whenever I offer to support their goals with things in my purview people are genuinely surprised and extremely appreciative. It sets the tone for a great relationship and partnership. * Experiential - Another potential friction point with stakeholders is the experience that they are having or have had in the past with your function, certain team members, or the approach the organization is taking to address a shared need or objective. Therefore, I often spend time while relationship building asking questions about my stakeholder’s experience. What do they think is working well vs what could be improved? Are there any friction points in the process we can address? Etc. If you are going to ask these types of questions, make sure you are ready and willing to hear the answers. Be very mindful of how you respond, because anything less than “Thank you so much for sharing that, can you please tell me more,” and you have negatively impacted your relationship with this stakeholder or partner as well as their likelihood to share this kind of feedback with you in the future.

The following sources of feedback are very important to me and my team: Customers our PM team is directly in contact with, as well as our direct digital feedback channels in the application Sales Teams - why do we lose deals, and why are we winning deals? Who is asking for what, and what is the context of the account (Rev, Use Case, Engagement, etc) Customer Success - What are current customers asking for help with? What are they frustrated by? What are they pushing for? Market Research - we keep a pulse on what our customers are feeling toward our competition, what our competitor's customers are feeling towards us, and many other examples like this that help us prioritize our roadmap. Usage data - if product areas are not being engaged with, we can make the decision to disinvest in that particular product area.

Product intuition is that elusive skill that we all look for and want to select, nurture, and encourage in our team members. If I had to break down product intuition, I’d break it down into the following parts: * Experience - having made the mistakes that make you aware of what to look out for (or learning from those that have) * Customer centricity - knowing on a deep level what your customers or potential customers need, want, and feel (deep empathy and understanding of their jobs and goals) * Reading the market - following trends both in your direct industry and competitive set, as well as more broadly in adjacent industries. * Communication/Storytelling Skills - being able to leverage the knowledge and awareness you have gained in the previous 3 points and articulate it in such a way that your cross-functional partners, customers, and prospects feel heard, seen, and validated. Hopefully, you are seeing a trend that each of these elements is also a skill that can be honed over time. They are not necessarily capabilities you either have or don't have, although some people have honed them so well that watching them work makes you feel like it is an inherited trait. Investing time in each of these categories to find a sustainable way to maintain your knowledge and comfort level with these skills over time is the key to developing and growing your product intuition. Pro tip - find people who impress you with their mastery of product intuition (or even any of the skills listed above) and observe them, talk to them, ask them questions, and try to glean insight into how they have developed their skills.

Prioritization is the most important role of the product management function, and there seems to be a general sense that there is one major moment of prioritization that culminates in a completed roadmap. The reality is that the exercise in prioritization starts much earlier. Like many organizations, we are resource-constrained and have many more ideas than we can realistically action. Therefore, prioritization is one of the most important things we can do to help the company succeed. This means we are constantly prioritizing at all levels of work, not just the roadmap items. Prioritization starts with the product strategy, and decisions around what we want the product to be known for, who the target buyer and users are, and how we plan to differentiate from other key players. It continues as you prioritize the problem spaces PMs and Designers are encouraged to explore and validate. It continues still as the opportunity sizes and strategic alignment of those problem spaces surface ones we choose to pursue solutions for, and so on and so forth. By the time you get to the prioritization of features for a roadmap, you have already made a series of decisions around priority that have led you there. We craft specific stages and ceremonies within our product development lifecycle to intentionally make those choices in a less biased and more intentional way. Even with the best prioritization processes though, you may still find yourself comparing a series of features to each other, trying to decide which is a priority for your roadmap. In this case, here are some elements our team thinks through: 1. Strategic Alignment - Are these items helping us intentionally pave our way to our intended future state, or are they requests that aren’t well aligned to our vision? 2. Perceived Value - Will customers/prospects find this feature or product valuable, especially when compared to the competition? 3. Technical Feasibility - Can we build it with the people, tools, and expertise we have? 4. Commercial Viability - Will this product or feature provide a positive financial impact on the business? 5. Product Differentiation - Will this help us differentiate against the competition? 6. Retention/Expansion Driver - Will this help us keep our existing customers happy, or provide opportunities to expand into other user groups, use cases, buyers, or fulfill other market needs? Depending on where your team lands on the quant/qual continuum you could simply assess these (or similar) elements categorically and make a call, or if you really like to be a bit more concrete, you can create a scorecard that you use to evaluate all features or initiatives against this set of criteria of your choosing.

Every new job I've taken has had a pretty specific challenge I was hired to solve, and I was fortunate to have that clarity (at least at a high level). When I start in the new role, I focus on the following elements: * Build relationships with my team and cross-functional partners * Learn about the industry * Study competitors * Explore the product in detail * Collect as much customer feedback and usage data as I can get my hands on * And last but not least, find all the skeletons (or as many as I can). - What does the sales team wish they had that the product team just won't prioritize? - What does customer success wish the product team did so they would get fewer repetitive requests? - What does the team struggle with when trying to ship high-quality products with velocity? - And I dig into these topics with each cross-functional partner. While I'm doing this, I'm also looking for things that have been tried and didn't work before. Once I have all that perspective, I pull together some data on the market, industry, competitors, and any other stimuli I think might be helpful for the team to have. I then schedule a brainstorming session. In this session, I guide the team through a series of exercises to uncover common themes we can align our initiatives around. In addition, I make meaningful progress based on the pain points they have all been voicing in my discovery sessions. Once I'm satisfied that I've pulled every last idea out of this group, I go off and start to create the skeleton of the vision. I ask key members of the team to do the same and schedule a follow-up where we can discuss it. From my point of view, we work together until the vision is complete. This usually means that it addresses many of the pain points and the broader team feels like they have been heard. I make any changes that are requested and then the socialization tour begins because, without alignment, your vision isn't getting very far. This recipe has worked consistently with slight modifications for each role. Hope it helps!

Every organization is different and has a different culture, different role definitions, different ways of getting work done, different objectives, secret sources of power, and unwritten rules. Finding out about as many of these things as you can as quickly as possible will be extremely helpful to you in your career. Lets start with the questions to ask your R&D partners (engineering, design, research, operations, and in some situations product marketing). Every company has challenges and opportunities within its physical or digital walls. You have an opportunity in the first 90 days to efficiently find out about the challenges and opportunities so you can more intentionally steer towards your intended outcome. I'll provide an answer from the perspective of the IC and the leader because the focus is a bit different. As an individual contributor your objective is to understand what elements can contribute positively to your effectiveness in this role, as well as the things that block progress. The most important thing to remember for these first conversations is that in order for you to get any useful insights that aren't just canned answers which maintain the status quo, people will need to trust you. Start building trust by asking these individuals about themselves. Find something that you both have in common to connect on, build some rapport, then dig into some of your questions (You'll get richer answers). Next you'll want to dig into the projects, people, process, and tools, as well as anything you have questions about that was covered in onboarding. Ask about anything you are unclear on relating to the topics mentioned. Remember to save some time for some unstructured discovery: -Who is the best product manager you have worked with and what made them great? -What do you hope this role will accomplish for the organization? -How can I be a great partner? -What works well here? -What doesn't work well here? -Where have others struggled? And my personal favorite.... Are there any topics or projects that are a touchy subject here? (I've avoided many awful situations with this one). If you're lucky, this one can help you avoid the traps. For product leaders, the altitude changes a bit. Instead of figuring out how you can be the best IC, your goal is to make sure the function is performing well in the organization. Adjusting the verbiage so that it's applicable for the product function should elicit some thoughtful responses. One question I'd recommend asking specifically is "how is the product managment function seen in this org?" Perception isn't always reality, but it can help you uncover glaring process gaps, or opportunities for relationship and rapport building between key groups. If you need a PR level overhaul for product managment, you'll be able to start sooner if you find out about it early and speed is of the essence. The elements you uncover with this exercise can help you formulate your most impactful short term contributions for your 30/60/90 day plan. For xfunctinal geoups like marketing, sales, support, and others, the questions can be similar, but it helps to get some more underlying detail from these groups. Ask if you can shadow a rep on the lifecycle of a deal to learn. Ask if you can see the distribution of support cases and shadow a support representative. Similar scenario for marketing on new campaigns and plans. Offer to be of service to build those relationships. Not only will these conversations help you learn so much about what is going on in the organization so yo can be more effective in your role, but once open, these lines of communication can keep you aware of shifts and changes for a long time to come. When asking for materials like these, remember to be a good corporate citizen. It would not be strategic to criticize it upon reciept, or talk about how inefficient those "other" roles and functions are. Use it to learn, help make it better if you can, but never throw stones with no positive intended outcome in mind.