A cornerstone of being a successful product manager is effective communication. Given the number of individuals, teams, and stakeholders a product manager interfaces with on a regular basis, mastering communication skills is something we should all be working on continuously. In my experience working with start-ups for the past 20 years, I’ve witnessed a lot of variance in the degree to which companies encourage employees to reflect on their strengths and weaknesses in order to identify how they can improve themselves. Often, these efforts center on communication. Tweet This: “A cornerstone of being a successful product manager is effective communication, and understanding personality types can help.” There are many ways to do this and, if you’re fortunate, your company has some process in place to help you. If you’d like to take things into your own hands, however, I recommend trying one of the following online assessment tools, which can help you uncover blind spots and strengths you may not even be aware of. There are many different assessment tools out there, each with its own framework and methodology. Myers-Briggs Myers-Briggs Type Inventory (MBTI) is one of the most popular personality frameworks, having been used since 1943. This framework is based on four dichotomies: whether you’re extroverted or introverted, whether you rely primarily on sensing or intuition, whether you’re a “thinker” or a “feeler,” and whether you rely more on judgment or perception. The results are boiled down to one of 16 personality types, such as ISTJ or ENFP. My test results indicate I’m an ENTJ, which means I’m matter-of-fact, decisive, and quick to make decisions. ENTJs also excel at helping people get things done with a focus on getting results in the most efficient way possible. Sounds like a product manager, right? So do many other MBTI types. ISTJ’s, for example, tend to be serious and earn success by thoroughness and dependability. Practical, matter-of-fact, realistic, and responsible, this also sounds like a product manager. If someone on your team is an ISTJ, she may not thrive in a chaotic, all-day brainstorming session. You may want to think of some alternative ways to solicit their input, such as having everyone write their ideas on post-it notes instead of saying them out loud. There is no right or wrong personality type. The key is to find your type and take advantage of the strengths you have. StrengthsFinder Speaking of strengths, StrengthsFinder is another popular assessment tool. As the name implies, this test is all about finding your top strengths so you can better take advantage of them. The methodology is based on understanding which of the 34 “talent themes” best represents your strengths. My top 5 strengths are Achiever, Activator, Positivity, Futuristic, and Learner. If you didn’t know me, but read the results from the StrengthsFinder test, you probably wouldn’t be surprised to find out I’m a software product manager. Another product manager I know is a Maximizer, Strategic, Learner, Individualization, and Arranger. Sounds like a great combination for a product manager! In this case, I might ask this product manager to take the lead on conducting data analysis along with presenting it to the organization since the Arranger trait makes him well-suited to identifying patterns and trends and perceiving how things fit together. DISC DISC is another framework I recently discovered which appeals to me because of its simplicity. It’s based on answering a set of 12 quick questions about how you respond to challenges, how you influence others, and how you respond to rules and procedures. I also like how it can easily be applied to understanding what makes other people tick without already knowing whether they’re an ESTP or an Activator. DISC is a quadrant behavioral model based on these 4 personality dimensions: Decisive (Ds): This type is best described as direct, strong-willed, and forceful. If you’re a fan of the Seinfeld TV show, Jerry would fall into this theme with his direct, skeptical, and impatient nature. Interactive (Is): If you’re sociable, talkative, and lively, you’re likely an I. Another I would be Jerry’s friend, Elaine. Stabilizing (Ss): Gentle, accommodating, and soft-hearted people are considered to be Ss, much like Kramer. Cautious (Cs): Questioning, analytical, and stubborn types enjoy accuracy and stability. Jerry’s best friend, George, certainly comes to mind when you think of the Cs. Once you know what your DISC type is (mine is D), you can easily start applying the framework to those around you. Does this require some generalization and stereotyping? Perhaps. However, it’s human nature to make judgements about people as soon as we meet them. This is rooted in our animal instincts to judge friend from foe, threat from opportunity, etc. By leveraging these insights to better understand your colleagues, you’ll be able to better communicate with them and be more successful in your product career. Take a moment now and think about someone on your team that you work closely with. Without giving it too much thought, which DISC type comes to mind? Once you get the hang of it, you can start using this in a more strategic fashion, such as tailoring your one-on-one meetings based on the DISC behaviors your colleague best represents. Grabbing coffee and having an informal chat would work well with an I style colleague. However, if you’re having an important meeting with an individual who is a C, then you need to prepare yourself by allowing enough time to go over the details with that person so that they can fully digest what you are presenting to them. You may even want to think about the types of questions he may ask you, since you know they tend to be questioning and analytical. A practical and creative use of this framework is to apply it to how you present your product roadmap to stakeholders. I always try to meet 1:1 with my stakeholders to socialize my roadmaps, to give everyone a chance to ask questions and dig deeper into what the vision is and what is driving our priorities. By tailoring these roadmap socializing sessions based on the DISC personality types, you’ll be able to much more effectively communicate product direction and build consensus. For example, you could choose different roadmap templates based on who you’re meeting with. If you’re meeting with someone who’s a D style (direct, fast-paced, impatient), you may want to share a streamlined version of your roadmap with a focus on results. If you’re meeting with a C style (think of George), come prepared with a more detailed roadmap with back-up slides to address their need for understanding the analysis behind the roadmap. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); Tailoring your roadmap presentations to your audience is a key to your success as a product manager. Better understanding your audience with the use of frameworks such as these can help you ensure your product has the best chance of being successful. Have you used other personality assessment tools? Please share them in the comments below.

After reading a blog or a book or attending a conference or talk on product management, I’m always excited to try out the new processes and frameworks I’ve learned about. I try to get my team similarly enthused about this endeavor. But when I check in with them in about a week, you can barely tell that anything had changed… mostly because it hadn’t. We tend to fall back into how we were doing things before because that cool new process isn’t meaningful in itself. Without the context for why it’s the most important way to spend our time, it wasn’t worth investing in making a change. So when I tried coming up with my own mindset and mantra for improving product management, I found myself elevating above the flowcharts and execution strategies, looking for something more universal. I wanted to tie together the entire ecosystem and to identify a unifying measuring stick. Something equally applicable to how we prioritize projects as it is to our own careers. Most importantly, I wanted to invest our time in something that will stick and make us all more productive and efficient product teams. Thus came the genesis of IMPACT, where six words can create a lens to reexamine everything a product professional does to ensure it truly is creating an impact and maximizing the opportunity. Meaningful Product Processes with IMPACT Solving Interesting problems that are Meaningful to People, with Actionable plans that are Clear and Testable. That’s what IMPACT’s all about, and if we’re not infusing our processes with IMPACT, then we’re potentially spending our energy on the wrong things. hbspt.cta.load(3434168, '76387af0-7ef4-49da-8b36-28e99e4f5ba3', {"region":"na1"}); Interesting By making the problem interesting, we start to build momentum. People need a reason to care, so it’s imperative we tell stories and use our storytelling skills in everything we do. By helping our audience—from sales and marketing to engineering and QA—connect with the customer problem, we will drive better outcomes. We all know that when we focus on value over features, everyone’s happier. The processes with IMPACT that help ensure we’re working on interesting problems include: Product discovery—Helps you better understand the customer problem and interestingly tell that story. Ideation & validation—Uncovers more meaning. Market research—Reveals how others tell their stories and perceive the audience. Customer feedback—A door into what’s happening and the trends and evolution in the market. Community involvement—Take any opportunity you can to be where your customers are and get more chances to hear their stories and the challenges they face. Event participation—Talk to people and learn about their lives outside your product for invaluable context. Meaningful Is your solution meaningful to the customer or the business? Remember that excitement about an idea doesn’t always translate to value. The real test is how much they’re willing to pay for it, which truly shows how much they value the solution. Aside from generating revenue, it’s also important to check if the solution aligns with the business’s direction, vision, and values. These processes with IMPACT can help you articulate what’s meaningful to business: Vision & Mission—Although it’s often handed down from senior management, it still influences your work. You should be able to articulate how your solution aligns with the vision and mission. Then, prioritize things when necessary to create those connections. Strategy/Strategic Alignment—It should include a definition of value that the product is trying to deliver and what success looks like. Gracefully Saying No—If that really compelling idea doesn’t create meaning, communicate that to teams and customers ASAP, then move on. Roadmapping—Include components of the meaning and value you’re creating, as well as why it’s the right thing to do. People You must figure out the pervasiveness of the problem you’re solving and how many people will care. What will solving this problem unlock in the market? Alongside understanding your research in solving the problem with a specific solution, it’s also essential to know how that investment may accelerate other innovations or solve related problems. This can lead to exponential growth and new opportunities beyond the original scope and scale of the situation. By using as broad a lens as possible, you can also determine if you’re making a big impact for a small number of people or a small impact for a big number of people… both of which are worthy and sound investments, assuming there’s a willingness to pay. These processes can help quantify things: Competitive Analysis—Helps you understand which problems competitors are solving and how they frame them. Not to mention figuring out which ones they’re NOT solving. Market research—Helpful, but determine upfront how much you need to know to be confident to move forward to avoid analysis paralysis. Surveys—Determine who cares about this problem and how frequently it occurs. Jobs To Be Done/Opportunity Tree—Another tool to assess the problem’s pervasiveness and how big a deal it really is. Prioritization—Be sure you’re accounting for the people that will be impacted by value creation. Not catering to the whims of internal stakeholders or finicky edge cases. Segmentation—Use this to define your target market and zoom in on the people who will truly benefit and appreciate the value of your solution. Actionable Coming up with a great idea is pretty easy. Go ask a first grader, and they’ll give you some amazing, innovative ideas… that are completely unfeasible. Your job is to narrow things down to what’s possible, reasonable, and probable. You need to know you can deliver the solution, regardless of how big or important the problem is. These processes can serve as a reality check on what’s truly doable: Squads/Team Composition—More effective teams, benefit the entire company. They must be constructed to get an optimal cross-section of talent and compatible personalities and work styles. Product Development processes—Find time to evaluate feasibility and LOE as early as possible to avoid wasting cycles un impractical pathways. Ideation/Validation—All ideas are welcome, but only those truly actionable given how the solution is framed should be pursued. Dependency Analysis—Larger teams, create more dependencies. Those dependencies increase the odds that the market will pass you by while you sort things out. Clear To build consensus, generate enthusiasm, and win over skeptics, you must be able to articulate the value statement of the solution clearly. This not only will help you secure resources and support for the project, but it also has a downstream impact on sales and marketing, as well as eventually how customers react to the value proposition. Some key processes contribute to making sure the impact of the solution is clear to everyone: Roadmap/Road Show—You want to make sure it’s in front of audiences frequently enough that it’s current, accurate, and remains top of mind. This is especially key when there’s not yet a lot of trust in you or your ideas. It’s also crucial to ensure the roadmap presents the right amount of information for the specific audience. You don’t want to drown them in details or rush through the items they particularly care most about. Alignment—You want to be sure you’re all using the same language, OKRs, prioritization, etc., so you’re all happy with the result. Cross-Functional Collaboration—Evaluate how and when you interact with peers to be sure it’s frequent enough. These interactions should be in settings where they’ll feel heard and can have their concerns addressed. Documentation—People don’t read (except amazing blog posts like this!). Is it accomplishing what you need it to do? Does it match the TLDR summary you included at the top? Testable Humans aren’t very good at knowing what they need, just articulating what they THINK they need. Therefore you must validate that the planned solution is valuable as early as possible. Embrace the sunk cost philosophy early and often. Additionally, don’t be afraid to walk away or initiate a significant course correction at any stage. This is only possible by leveraging processes that put your ideas to the test: Agile Product Development—Agile is about more than replacing waterfall; it’s how you can test, learn, and adjust. With Agile, you can forward efficiently while leaving room for learning moments and making corrections based on those findings. Beta Processes—It’s never too late to learn and change. Set expectations internally and with customers while capturing feedback during beta tests. This isn’t just a dress rehearsal but rather a chance to get real-world experience on what you think will work. Iterative Design—Boil things down to the smallest step you can take to deliver value. Then test, learn, and repeat. Usability Studies—You need tools to test and verify. So watching real customers try to use your product is one of the best options there is. For more insights into how you can apply IMPACT to your processes, watch the webinar or download the free e-book today.

After reading a blog or a book or attending a conference or talk on product management, I’m always excited to try out the new processes and frameworks I’ve learned about. I try to get my team similarly enthused about this endeavor. But when I check in with them in about a week, you can barely tell that anything had changed… mostly because it hadn’t. We tend to fall back into how we were doing things before because that cool new process isn’t meaningful in itself. Without the context for why it’s the most important way to spend our time, it wasn’t worth investing in making a change. So when I tried coming up with my own mindset and mantra for improving product management, I found myself elevating above the flowcharts and execution strategies, looking for something more universal. I wanted to tie together the entire ecosystem and to identify a unifying measuring stick. Something equally applicable to how we prioritize projects as it is to our own careers. Most importantly, I wanted to invest our time in something that will stick and make us all more productive and efficient product teams. Thus came the genesis of IMPACT, where six words can create a lens to reexamine everything a product professional does to ensure it truly is creating an impact and maximizing the opportunity. Meaningful Product Processes with IMPACT Solving Interesting problems that are Meaningful to People, with Actionable plans that are Clear and Testable. That’s what IMPACT’s all about, and if we’re not infusing our processes with IMPACT, then we’re potentially spending our energy on the wrong things. Download IMPACT ➜ hbspt.cta.load(3434168, '76387af0-7ef4-49da-8b36-28e99e4f5ba3', {"region":"na1"}); Interesting By making the problem interesting, we start to build momentum. People need a reason to care, so it’s imperative we tell stories and use our storytelling skills in everything we do. By helping our audience—from sales and marketing to engineering and QA—connect with the customer problem, we will drive better outcomes. We all know that when we focus on value over features, everyone’s happier. The processes with IMPACT that help ensure we’re working on interesting problems include: Product discovery—Helps you better understand the customer problem and interestingly tell that story. Ideation & validation—Uncovers more meaning. Market research—Reveals how others tell their stories and perceive the audience. Customer feedback—A door into what’s happening and the trends and evolution in the market. Community involvement—Take any opportunity you can to be where your customers are and get more chances to hear their stories and the challenges they face. Event participation—Talk to people and learn about their lives outside your product for invaluable context. Meaningful Is your solution meaningful to the customer or the business? Remember that excitement about an idea doesn’t always translate to value. The real test is how much they’re willing to pay for it, which truly shows how much they value the solution. Aside from generating revenue, it’s also important to check if the solution aligns with the business’s direction, vision, and values. These processes with IMPACT can help you articulate what’s meaningful to business: Vision & Mission—Although it’s often handed down from senior management, it still influences your work. You should be able to articulate how your solution aligns with the vision and mission. Then, prioritize things when necessary to create those connections. Strategy/Strategic Alignment—It should include a definition of value that the product is trying to deliver and what success looks like. Gracefully Saying No—If that really compelling idea doesn’t create meaning, communicate that to teams and customers ASAP, then move on. Roadmapping—Include components of the meaning and value you’re creating, as well as why it’s the right thing to do. People You must figure out the pervasiveness of the problem you’re solving and how many people will care. What will solving this problem unlock in the market? Alongside understanding your research in solving the problem with a specific solution, it’s also essential to know how that investment may accelerate other innovations or solve related problems. This can lead to exponential growth and new opportunities beyond the original scope and scale of the situation. By using as broad a lens as possible, you can also determine if you’re making a big impact for a small number of people or a small impact for a big number of people… both of which are worthy and sound investments, assuming there’s a willingness to pay. These processes can help quantify things: Competitive Analysis—Helps you understand which problems competitors are solving and how they frame them. Not to mention figuring out which ones they’re NOT solving. Market research—Helpful, but determine upfront how much you need to know to be confident to move forward to avoid analysis paralysis. Surveys—Determine who cares about this problem and how frequently it occurs. Jobs To Be Done/Opportunity Tree—Another tool to assess the problem’s pervasiveness and how big a deal it really is. Prioritization—Be sure you’re accounting for the people that will be impacted by value creation. Not catering to the whims of internal stakeholders or finicky edge cases. Segmentation—Use this to define your target market and zoom in on the people who will truly benefit and appreciate the value of your solution. Actionable Coming up with a great idea is pretty easy. Go ask a first grader, and they’ll give you some amazing, innovative ideas… that are completely unfeasible. Your job is to narrow things down to what’s possible, reasonable, and probable. You need to know you can deliver the solution, regardless of how big or important the problem is. These processes can serve as a reality check on what’s truly doable: Squads/Team Composition—More effective teams, benefit the entire company. They must be constructed to get an optimal cross-section of talent and compatible personalities and work styles. Product Development processes—Find time to evaluate feasibility and LOE as early as possible to avoid wasting cycles un impractical pathways. Ideation/Validation—All ideas are welcome, but only those truly actionable given how the solution is framed should be pursued. Dependency Analysis—Larger teams, create more dependencies. Those dependencies increase the odds that the market will pass you by while you sort things out. Clear To build consensus, generate enthusiasm, and win over skeptics, you must be able to articulate the value statement of the solution clearly. This not only will help you secure resources and support for the project, but it also has a downstream impact on sales and marketing, as well as eventually how customers react to the value proposition. Some key processes contribute to making sure the impact of the solution is clear to everyone: Roadmap/Road Show—You want to make sure it’s in front of audiences frequently enough that it’s current, accurate, and remains top of mind. This is especially key when there’s not yet a lot of trust in you or your ideas. It’s also crucial to ensure the roadmap presents the right amount of information for the specific audience. You don’t want to drown them in details or rush through the items they particularly care most about. Alignment—You want to be sure you’re all using the same language, OKRs, prioritization, etc., so you’re all happy with the result. Cross-Functional Collaboration—Evaluate how and when you interact with peers to be sure it’s frequent enough. These interactions should be in settings where they’ll feel heard and can have their concerns addressed. Documentation—People don’t read (except amazing blog posts like this!). Is it accomplishing what you need it to do? Does it match the TLDR summary you included at the top? Testable Humans aren’t very good at knowing what they need, just articulating what they THINK they need. Therefore you must validate that the planned solution is valuable as early as possible. Embrace the sunk cost philosophy early and often. Additionally, don’t be afraid to walk away or initiate a significant course correction at any stage. This is only possible by leveraging processes that put your ideas to the test: Agile Product Development—Agile is about more than replacing waterfall; it’s how you can test, learn, and adjust. With Agile, you can forward efficiently while leaving room for learning moments and making corrections based on those findings. Beta Processes—It’s never too late to learn and change. Set expectations internally and with customers while capturing feedback during beta tests. This isn’t just a dress rehearsal but rather a chance to get real-world experience on what you think will work. Iterative Design—Boil things down to the smallest step you can take to deliver value. Then test, learn, and repeat. Usability Studies—You need tools to test and verify. So watching real customers try to use your product is one of the best options there is. For more insights into how you can apply IMPACT to your processes, watch the webinar or download the free e-book today.

This article is for recent graduates with an entrepreneurial mindset who are thinking about what would be the perfect job for them. It’s also for people thinking about moving into product management. I’m going to start with a question. Raise your hand if someday: You’d like to start your own company? Be your own boss? I’m visualizing lots of hands raised out there. I mean, dang, who wouldn’t want to have their own company, be their own boss, and call the shots? For that reason, I’d like to introduce you to a job title you may not have heard of before, but that could give you some runway to practice the skills you might need to start your own company someday — while you still get a great paycheck, benefits, and learnings from a more established company. That job title is Product Manager. Here’s why product management should be your career choice. You’re in great company. There are some famous people out there who were first product managers before they started being CEO. Here are just a few: Jeff Bezos – Amazon Kevin Systrom – Instagram Marissa Mayer – Yahoo And while I’m nowhere close to those three groundbreakers, I have worked at Citrix for over 14 years, leading teams developing and releasing the GoTo branded software that generates millions of dollars in annual revenue. Do I have a degree in computer science or human-computer interaction? No. What might surprise you is that I was a Liberal Arts major in college; I studied Spanish. Long story short, by taking various jobs in the software industry and constantly learning and moving up, I was able to grow my career from web designer to user interface designer to product manager. I ultimately became a product manager because of some of the skills below that I realized I always had. Loosely put, the product manager sets the tone for a product, understands the customer’s pain points, leads a team, takes various forms of input, and ultimately makes the product-related decisions. The elephant in this picture is the leader of the pack. It’s almost like her trunk and her feet are pointed in one direction, and as if she is saying: “Follow me” “We’re going that way.” “We are passionate and are we’re on a mission.” Ok, I’ve got you to this point and so you ask, “What companies need product managers?” Kind of a simple answer, but any company that has a product or service needs someone to truly understand the needs of its customers and to set the vision and tone for the product and for the people who work on it. In a small company of 1-20, it’s usually the founders, but at some point, the founders have other things to do and may appoint a product manager. In larger companies, there’s almost always a need for many product managers. Quick gut check. Searching on LinkedIn TODAY, I found (obviously subject to change on the day of search but this gives you a sense): 1,019 Product Management jobs at Amazon 455 at Google 303 at Facebook Before I go too far, let me just say: different companies call “product managers” different things. You find similar jobs under the following names: Product Marketing Manager Program Manager Project Manager Product Owner Use those terms and you’ve just expanded your search 3x. So now that you know what it is and what it might be called. Let’s see if it might be a fit for you. Are You a Ringleader? Then product management might be the career choice for you. People who like other people, who have the ability to wrangle and lead various folks, (while respecting their opinions and differences) are what I might call Ringleaders. If that’s you, take note. Ringleaders make great product managers because they: Recruit other passionate people who never give up to be on their team. Enable their teammates to shine and do their best work incorporating their feedback. Gather champions and mentors to guide them along their product journey. Buy the pizza, bring the donuts, and make sure everyone is fed — literally and figuratively. If anyone needs something or is blocked, the product manager is the first one to help. As servant leaders, they eat last and let others go first. hbspt.cta.load(3434168, 'a6df8971-315b-4e8c-ad02-5e133239bfda', {}); Are You a Curious Observer of Life? There are some people who love observing the curiosities of life and work. They wonder why things work a certain way and if there might be another way. This is just how they tick — all the time. If that’s you, good news: constant and relentless curiosity is the most essential tool in a product manager’s toolbox. They use it to: Ask a lot of questions about their customers, their teams, and the market. Why? is their favorite question. Lean in and listen to the answers thoughtfully, without bias. Observe people in their natural setting (because “actions speak volumes”). You’ll hear them say, “Huh, isn’t that interesting.” Do You See Opportunities? Once you spot a problem or something that could be made better, do you instantly go into thinking, evaluating, and what-if mode, running quick calculations in your head, sketching rough ideas on the back of a napkin? Do you brainstorm with a friend asking, “How might we…?” or “What if…?” If yes, you really should think about a career in product management. Because product managers constantly: Narrow in and focus on the most pressing problems that offer the biggest opportunities for their customers and their companies. Believe, hypothesizing the possible ways they can make a difference. Experiment and iterate rapidly so they can learn fast if their beliefs are true or false and how they might make their solution more irresistible. Tell stories that are easy for anyone to comprehend and get onboard. Are You Problem Maker or Problem Solver? And then there are people who don’t make problems but solve problems. They’re the first ones with an idea, a fix, or a plan. They are not phased — in their eyes, if there’s a will, there’s a way. They aren’t complainers but doers, makers, fixers, and dreamers, envisioning a better or new way. Does that sound like you? If so, product management is all about solving problems; jumping through, around, over, and under obstacles; and asking questions like: How might we solve this? What’s the one standout thing that makes our solution different, better, easier, or cheaper than what is out there today? What competitive advantages do we have that we can run with? While I was at Citrix, we had the opportunity to come up with a startup app idea when the company was interested in developing lean and scrappy ideas to compete with ankle-biting startups. Along with 4 teammates, we came up with a phone app called Convoi that was targeted at everyday business people who were tired of using their personal cell phones for work but needed a mobile phone number for texting, calling, and business voicemail with clients. Our one standout thing was that within 15 seconds of downloading our free app, we got you any phone number in any area code. You could immediately be calling and texting from it. It was a magical experience for people. We had a trusted audience from GoToMeeting that we could advertise for free. In the app store, we could be a sister app to GoToMeeting that had over millions of downloads each year. We could ride that wave and get eyeballs and attention without spending a lot of money on marketing. We had the advantage of being part of a large company that had resources we could use to build the app, validate it, and get it to market fast. We knew the company was interested in the virtual phone system business but hadn’t yet pulled the trigger on a large scale development project. We could afford to offer something as freemium to test the interest. We found mentors and champions internal and external to the company to guide us on our way. You Understand That You Have to Show Proof Because they have so many ideas, these kind of people are anxious and want to know if their solution will work — if it will hold water. The bosses funding these projects also want to see proof that they’re on the right track. They usually come up with metrics, triggers, or tests to tell themselves and their teams whether they’re on the right track. Is that you? If so, product managers routinely ask themselves and their teams: How will we know it’s working? What does success look like at certain points in our journey? What are some success metrics or numbers we hope to hit? In the Convoi example above, we had some metrics we held ourselves accountable. Here were just a few of ours: 25 interviews of our target audience saying that they had this problem and were actively looking for a solution Time To Value < 30 seconds First text sent/received < 5 mins > 5% new users per week Net Promoter Score > 50 40% Daily Active Use (It was a business phone so in order for it to be successful you had to use it every week day) By hitting these we knew we were on the right track. Are You Adaptable? Then product management might be the career choice for you. Some people crave change, love the challenge of it, and can turn on a dime. They actually thrive on the adrenaline. They love hard things that might not have been done before. They are on a relentless pursuit of “yes”. The word “no” doesn’t phase them for too long. “No” might be a no for today, but tomorrow the game is different. Product managers know that: Change will happen. Companies, plans, roadmaps, and management change. You have to be willing to pivot when the data is telling you to do so. They are constantly iterating and reinventing themselves. They will ask and be turned down 80x. It’s part of the journey. They write their own playbook when there isn’t one (which is quite often). They learn from others. They figure, why reinvent the wheel? In short, a product manager’s job is all about solving problems for people. If your life has led you to creative thinking, problem-solving, and curiosity, it’s quite possible product management is the perfect career choice and you’d be a perfect fit for a role where you can practice, learn and grow a ton. A role in product management will look terrific on your resume, and the learnings will be great while the risk is minimal. What’s more, you will likely earn a favorable salary (check GlassDoor for product management salaries — not too shabby) and be instilled with the confidence that you might just start your own company someday. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); About the Author Carey Caulfield (@careycaulfield) works at LogMeIn in the GoTo business division previously part of Citrix Systems in Santa Barbara, CA as a Principal Product Manager. Her background is in Software Design, User Research/Experience, and practicing LeanStartup within large companies. She’s helped to design and launch three of their flagship products – GoToMeeting, GoToWebinar, and GoToTraining. Most recently, she and four other hackers lead from behind with a tiny startup idea called Convoi that turned your personal iPhone into a second business phone, influencing the decision to go into the virtual phone service business. She mentors user researchers, product managers, and Engineers unfamiliar with the principles of LeanStartup to be 120% customer focused at leanproductcoach.com.

When I started my career as an engineer, I didn’t set my sights on becoming a product manager. Flash forward fifteen years later, and I’m the Director of Product Management at HG Insights. Working in startups and big technology companies, I’ve encountered one question more than most: “How do I make the switch from engineering to product management?” That’s a big question, and many roads lead to this outcome. So, what qualities does it take to become a product manager? What differences lie in the company expectations? Moreover, what are the next steps you can take to make the transition? My Journey Transitioning from Engineering to Product Management I worked 9+ years in software development, leading sizeable cross-functional engineering teams across time zones. Then, I started gravitating towards product strategy questions, like, “Why am I building products?, Who am I building for?, What impact am I bringing to the business?, What makes startups fail or succeed in their mission?”, and so on. I thought Business school would be the answer, so I started preparing for it, but an exciting opportunity fell in my lap to transform a struggling product offering. Though I had no idea what I was doing before I knew it, I interviewed external customers, internal stakeholders, and various customer-facing teams to understand the problem better. I worked with the product leadership to plan out a product strategy. Then, I created a product roadmap to move that strategy forward, which ultimately drove a 15% increase in revenue and a 20% increase in retention. I believe in focusing on outcomes to power-up aligning your product strategy with business goals onto a roadmap. It was the most satisfying moment of my career, even more than building multiple product lines. From that success, I was then officially asked to move into the product role by the product leadership, and I have not looked back since then. hbspt.cta.load(3434168, '1f74539e-d4fc-4cb3-97c6-fd86de2bf62e', {}); 4 Key Differences in Skills Engineer to Product Manager You don’t need to have an engineering background to be a successful product manager. Anyone can learn agile product development, basics of software design and development lifecycle, etc. Here are the four fundamental elements product managers need that is different than engineering: Strong empathy for your customers (internal and external) Strong understanding of the business (and market) You understand that your goal is to achieve business outcomes through measurable product initiatives. Your role is to identify and validate the problems, not actually to solve them. Participate in every aspect of product design (not talking about just UX/UI here), but this subtle distinction is key to not lose focus on the big picture. In addition to core product management skills, there are other essential intangibles to success like strong communication, cross-team alignment, being the thought leader, and always being curious. I shared more of my thoughts on this in the LIKE.TG video series, Spotlights. Watch them below. What are the Company’s Expectations of a Product Manager? As a product manager, your primary goal is to deliver business outcomes. Depending on the company, experience, team structure, and business dynamics, the expectations could vary. But any product manager not focusing on essential KPIs like active use, revenue, retention, customer satisfaction, etc. needs to take a closer look at the role. A good product manager is expected to drive strong cross-functional alignment and proactive communications to ensure everyone is focusing on the right problems. A wise woman once said: Product management is one of the hardest functions in the business but if done right can transform the entire business. Engineer vs. Product Manager Responsibilities The fundamental difference product managers need to understand is that your role is to identify the right problem (business, technical, or customer) and why it is worth solving or how it drives business outcomes. In contrast, engineering is responsible for delivering the solution to that problem. Your role as a product manager is to ensure your team is working on solving problems that have a measurable impact on the business. You are also responsible for ensuring customer-facing teams like Customer Success, Marketing, and Sales are fully aware and aligned on the product roadmap. Of course, a team is successful only when they collaborate as “one team,” so expect to roll up your sleeves for designing the solution, testing it, providing early feedback, documentation, etc. How to Transition from Engineering to Product Management First and foremost, you need to understand what product management is in your business and what they are responsible for. Every business, every team, and every market is different. To be a product manager, you need to start thinking like a product manager (even before switching over). There are plenty of books, blogs, and online training to sharpen up on the responsibilities. The best recommendation I can give you is to pair up with a product manager to get that hands-on experience. Start to learn how to approach a problem, define a problem, build hypotheses around solutions, collaborate with cross-functional teams to refine it, build metrics for success (or failure), and finally figure out the best and fastest way to get to market. The Transition from Engineering to Product Management Timeline In spite of popular belief, there are no definitive timelines, whether it’s engineering or product management. The first and most important thing is finding a company with an established product management team. Then, collaborate with an experienced product manager on a real project. I am personally a big proponent of the associate product manager track. That’s the best way to get your hands dirty in the game. Long term, you can expect to manage a specific KPI (e.g., improve first user experience, reduce churn, etc.), product offering, entire product portfolio, or product team. You have a little more flexibility in product management because you are learning various aspects of running a successful business. Takeaways Mentoring and people development is a big passion of my life and gives me more satisfaction than anything else. I talk to a lot of aspiring PMs who want to be product managers because they want to be a product manager or have a very different understanding of the role. I don’t blame them because there is so much wisdom that’s out there, which could be confusing sometimes. But if you like solving complex business problems and understand why and for whom, then you might like being a product manager. Look at your career as a marathon and not a sprint. Great products take time. Find the right business and team and learn faster than anyone else. Remember, slow is smooth, and smooth is fast.

I still cringe when I think back to the first roadmap I put together. Like most of us who find ourselves in product management, at the time I didn’t even realize I was doing “product management.” I was the lead of a UX team and saw a bottleneck between our work is designed and being implemented by the development team. So I sat down and wrote out the requirements and the order in which I thought the work should be done. As you might expect, it was a terrible roadmap. Cobbled together in a spreadsheet with links to a prototype serving as the only design specs, there was little visibility into what we were building, let alone why. I can’t believe my teammates put up with it. Thankfully, much has changed since then. For starters, I’m officially running product at my new company, Notion. More importantly, we have a process in place for team-wide alignment on our roadmap thanks to increased visibility and understanding of why we are building what we are building. We accomplished this by gathering what we call Little Data to tell the story of how we align and adjust our roadmap. Aligning the Roadmap LIKE.TG’s Planning Board feature is a great way to align your team around upcoming features. Thanks to their built in Weighted Scoring Model, it’s easy for the entire team to rate features as they relate to your goals as a company. At Notion, our benefits are designated by Customer Signal, Quarter Strategic Value, and Growth Opportunity. In other words, we rate a feature based on how high the demand is, its alignment with our growth goals, and how marketable it is. Our costs are broken down by Estimated Sprints, Unknowns, and Risk. These help us identify how long a feature will take to build, how much discovery still needs to happen, and whether or not the feature jeopardizes other elements of the app or user experience. After rating and reviewing these as a team, we are left with a prioritized list for the quarter based on the final score of each feature. That doesn’t mean we always build in that exact order, but we now have a baseline to measure any changes to the roadmap against. If anyone on the team wonders why we are building something, we can point back to the list and (hopefully) be able to explain our decision process. It’s a massive improvement from the laundry list of features I used to keep in Excel and has really increased team buy-in on what we are building. To learn how to build a data-driven roadmap of your own, watch LIKE.TG’s webinar: Adjusting the Roadmap The prioritized list from LIKE.TG serves another purpose. The synthesis of the costs and benefits correlates to the perceived value we are delivering to our customers. The higher the rank, the higher the value. This is critical data to reference as we measure our success goals since the other half of owning a roadmap is being able to make adjustments to it. hbspt.cta.load(3434168, '1f74539e-d4fc-4cb3-97c6-fd86de2bf62e', {}); We gather this data in Notion itself. As a tool, Notion brings together team, product, and performance data to help you make smarter, faster decisions. This means as a team, we are able to dogfood our own product to improve our own product. At the end of each sprint, we poll the team on a few team health metrics, one of which is how much value we think we are delivering to our customers. We can compare that value alongside other metrics we track in Notion like conversion rates, growth rates, and user activity around specific features. A dip in delivered value may result in undesirable drops across the board. We’re also in frequent contact with our customers to get a better sense of what is and isn’t working for them. If adjustments need to be made, we use this data to support our decisions. We can go back to the Planning Board and identify where we may have missed in our initial estimations, make the necessary adjustments, and document it so we can avoid the same mistake again in the future. Getting Started If you are interested in approaching your roadmap this way, my best piece of advice is this: Start small and be flexible. There is no secret set of metrics that will apply to every team or company. Plus, your needs and goals as a company will most likely change over time. Align your team by creating visibility into and understanding of your roadmap goals. Once this exists, the metrics you need to track should be easier to identify. For more tips on how to get started, you may find our School of Little Data helpful. Or feel free to reach out, we’re always happy to chat. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); About the Guest Author: Kevin Steigerwald has been designing, researching, marketing, planning, and building products big and small for over 10 years. He is currently the co-founder and CPO of Notion in Portland, Oregon.

There’s no shortage of sage advice for product managers. However, all advice may not be the best advice. To rectify this, we’ve sifted through years of our articles, blog posts, and books to provide you with the top six product management tips. These nuggets of wisdom—based on decades of experience in this unique profession—focus on what’s essential. While you might disagree with our curated list, we believe you will find at least one of our product management tips useful in your career. Our 6 Best Product Management Tips 1. Always take a collaborative approach Probably one of the most important product management tips is to take a collaborative approach. Each individual has a unique approach to accomplishing a task. They have different work styles, communication preferences, and opinions. Working with others comes with a host of challenges. Yet, though complex at times, those challenges bring a ton of value to the table, especially when working with engineering and design teams. In some organizations, the three-way relationship between the coders, designers, and product people may lead to teams challenging each other. Collaboration can help each team come to a consensus and find common ground. Contentious environments discourage innovation and risk-taking. Product professionals need to be aware that varying insights and ideas are available when everyone gets a voice. By welcoming stakeholders from different departments into the conversation, the product and its customers reap the rewards. From assessing an idea’s feasibility to unconventional user experience concepts, feedback helps the product team prioritize better. They can provide optimal solutions that encompass the ideas and solutions from both the engineering and design teams. The partnership often pays further dividends throughout the product development process as a closer and trusting relationship creates a more open and honest dialogue. Minor issues get raised and addressed before they become big problems when everyone feels like they’re on the same team. Watch our webinar below: 2. Be confident in your soft skills Product managers don’t necessarily need to be technical, but they need to work well with others. They have become adept at communicating with stakeholders, listening to customers, and developing empathy, which doesn’t come naturally. Developing your soft skills remains an essential product management tip. It’s essential to understand why these soft skills are imperative. Practicing and honing these things makes you a better product manager while simultaneously making your job easier. Listening skills Let’s start with listening. Addressing your customer’s problems requires a deep understanding of the issues they face. Though, it’s understandable that a lot of us dream about the prospect of reading our customers’ minds. Instead, you find out what really matters by talking to customers, asking them questions, and—most importantly—listening to what they have to say. The most successful product managers are active listeners who engage in follow-ups and have a general openness to customer feedback, which doesn’t come easily to everyone. Check your impulses, move into “receiving mode,” and take the feedback in with as open a mind as possible. Empathizing with customers allows you to feel their pain. By placing yourself in their shoes, you can evaluate and appropriately respond to their feedback. Communication skills Communication, of course, is a two-way street, so your listening skills should match your ability to convey information clearly. As a product manager, you need to understand their biases and assumptions when framing your message and deliver it via a method that will garner a response. Not everyone has the same communication style or prefers the same medium. The burden then falls upon you to tailor your communication based on the individual or group. The skills listed above merely scratch the surface when utilizing soft skills to improve your effectiveness and efficiency as a product manager. Serving as a product evangelist, facilitating stakeholder alignment, and leading prioritization exercises are a few other examples where these essential capabilities come into play. hbspt.cta.load(3434168, '83f51649-b6bd-42f2-9c45-d58c5fba5ca3', {"region":"na1"}); 3. Manage your own career A fatal flaw for any employee is to expect others to worry about their career development and progression. For this reason, we ranked “manage your own career” as one of our top product management tips. While managers and mentors may step up and take you under their wing, your boss may be solely focused on shipping products and keeping things under budget. Product professionals should always be mindful of their career path with no guarantee that anyone else will look out for their interests and invest in their future success. Successful product professionals build up their skills by getting the experiences they need to round out their resumes. Furthermore, they identify and pursue opportunities for growth and advancement. Product management professionals face additional challenges in advancing their careers because so much of what they do is behind the scenes. To bolster your image and get on the radar of hiring managers, use platforms such as all-hands meetings to promote yourself internally while participating in industry events to maximize networking opportunities and finding other chances to become a thought leader in your space. 4. Embrace visual roadmaps In the age of Agile, product managers don’t produce as many requirements documents. Our user stories reside in the tools of the product stack, and our insights get shared in standups and prioritization meetings. In turn, a scant “paper trail” of evidence of our hard work and an absence of documentation reviewed and referenced by stakeholders. Product roadmaps, however, remain the exception, and their importance has never been greater. Some product managers cram everything into their roadmaps since it’s the only documentation colleagues will see. Then again, the concept goes against the “less is more” rule of thumb, which guides everything product managers produce. Instead, leave out the details and allow visual roadmaps to be one of your essential product management tips. Themes tell the story, color-coding ties work items to desired outcomes and goals, and the focus remains on the items of strategic importance. And, when you use a purpose-built roadmapping tool such as LIKE.TG, you’ll spend less time creating and updating these visual roadmaps and be confident that stakeholders are always viewing an up-to-date version. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); 5. Don’t settle for a stale prioritization framework Figuring out what to build next and leave out is a key part of product management. To make it collaborative and incorporate multiple viewpoints and opinions, using prioritization frameworks for these exercises gets more folks involved and creates additional transparency to silence the naysayers. However, we live in the golden age of prioritization methods, so product teams shouldn’t stick with a framework that doesn’t truly fit their business. With dozens and dozens to choose from, each with its strengths and weaknesses, make sure you and your team are satisfied after using them. It can also help to shake things up now and then and try a new framework. Not only can it turn up some new insights, but it may also reinvigorate the entire prioritizing team by giving them something new. 6. Lead with IMPACT Our final top tip emphasizes prioritization differently. It’s a mindset universally applicable to every aspect of product management, from who you hire to what you work on to how you spend your time. Using a consistent lens, product teams can ensure they’re focused on what matters most by assessing how each potential item rates against these six fundamental aspects: I – Interesting: Does this address the things our customers care about? Can we tell a story of how we’re creating positive change for them? M – Meaningful: Are we moving the business forward toward measurably reaching its goals? Are we providing real value to our users? P – People: Who is impacted by this? Who uses it, who sees the benefits, and who pays for it? A – Actionable: Are we coming up with ideas that can be implemented and realized? Do we have the resources, budget, and expertise to execute? C – Clear: Do we truly understand what we’re trying to do? Can it be concisely articulated so even a child could understand? T – Testable: Can you try things out before committing? Are there ways to experiment and measure success on an ongoing basis? Keeping IMPACT top of mind helps everyone maximize the value they’re creating and keep their eyes on the prize. Download our free ebook to explore how to incorporate it into different facets of your work and career. Looking for more pointers on excelling in product management and other product management tips? Visit our Learning Center today.

As 2016 comes to an end, we’ve looked back and reviewed over 70 product management articles that we’ve written and published on our blog this year. Most of our topics covered product strategy, entrepreneurship, product management, roadmaps, marketing, agile development, and product management career recommendations. Our articles triggered some great conversations with fellow product managers on our blog and on social media. Here are our five most popular articles of 2016. Enjoy! #1: Roadmap Examples Our three blog posts detailing example roadmaps for product management, marketing and IT teams were by far our most read articles of 2016. Tweet This: “Roadmaps were the most popular product management topic of 2016.” Example Product Roadmaps Product roadmaps come in all shapes and sizes, and of course there is no such thing as a one-size-fits-all roadmap template. Your strategic plan, and the roadmap that represents it, will depend on many factors, including the stage of your product, the size of your company, the stage of your company, and the nature of your industry — just to name a few. However, there are some things that all good roadmaps have in common. Read this article to find out what they are, plus see three example product roadmaps to get your creative juices flowing. Example Marketing Roadmaps Roadmaps aren’t just for product managers. Marketing teams can also benefit from a high-level strategic plan. After all, how many times have you sat in a marketing meeting, listened as the discussion jumped randomly from topic to topic, and wondered: “Can we take a step back? Can we first discuss how all of these details are related, and why we’re talking about them?” In this post, we walk you through an example marketing plan, an example product launch plan, and an example digital marketing roadmap. These marketing-oriented roadmaps can help you create a strategic framework for otherwise disparate initiatives. Example Technology Roadmaps Roadmaps can also be invaluable tools for teams working on complex IT initiatives, such as upgrading a company’s technology infrastructure, for example. The key to a successful technology roadmap — as with any type of roadmap — is its ability to quickly and effectively communicate the strategic plan to the right constituents. The audience for a technology roadmap will often be stakeholders looking to the IT team for delivering internal-facing systems and solutions. In this post, we share an example technology roadmap, an architecture roadmap, and an enterprise IT roadmap. And we have plenty more examples; check out our entire library of 18 example roadmaps to kick-start 2017. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); #2: 5 Lies Product Managers Tell Themselves Do you call yourself the CEO of your product? Do you believe all product decisions must go through product management? Well, you’re wrong, but at least you’re not alone. Don’t take the “Product CEO” moniker too seriously. At the end of the day, you don’t get to boss around your CTO or Ops VP. And even though, as a product manager, you are ultimately responsible for your product’s successes and failures, you are not — and should not be — the sole decision-maker. It’s important to remember that a key ingredient in successful product management is team-building — creating an atmosphere of camaraderie among your colleagues and a common sense of purpose. This post highlights common (yet misguided) refrains in our product management community. Be sure to read up on these 5 lies so that we can all please stop telling them in 2017. #3: Lean Market Validation — 10 Ways to Rapidly Test Your Startup Idea In this article, Jim emphasizes the importance of questioning your assumptions, interviewing users, and shifting the focus away from features and toward your product’s value proposition. Read the full post to see Jim’s widely circulated 10-step formula for getting your product from concept to market, and ensuring its success by validating it with real prospects at every step of the way. Bonus: The article includes a slide deck from Jim’s presentation. #4: 7 Ways to Build an Awful Product This 7-step formula for building a terrible product was another hit. Every product manager feels the pressure to develop her category’s leading product. But here’s something you’ve probably never considered: Nobody’s competing for the middle slots in their product category. Or the bottom. So without much effort at all, you can own those positions. In this article, we explain how. Some of our tips include designing by committee, including every feature you can think of, and blindly copying your competitors. What the world needs are more awful products. So if you’re looking to launch a dud next year, be sure to do your homework. #5: Help! I’ve Been Handed a Bad Product Strategy What happens when the product management challenge you face is that you have poor strategic direction to begin with? This happens all too often. And it happened to a product manager who attended a recent Pragmatic Marketing webinar on thought leadership. In this post, Jim Semick shares how to fix a poor a product strategy, and explains some of the factors that can cause you to get stuck with a bad strategy in the first place. These factors could include: Software companies wanting to deliver new features. Executives working on assumptions — not always grounded in fact. Growing companies feeling the need to keep their developers busy. Product owners becoming information silos. Read on to learn more about common challenges, and more importantly, how to course correct. In Summary Developing and executing your product strategy was a focal point in 2016. From defining your product strategy, to lean market validation, to dealing with an inherited poor product strategy, product managers at companies of all stages are looking for ways to improve their strategic plans. Tweet This: “Developing and executing your product strategy was a focal point in 2016.” That’s why it isn’t surprising that example roadmaps were our most popular topics this year — after all, the purpose of a roadmap is to communicate your product strategy and keep your organization aligned on the big picture goals. The right product roadmap software can go a long way towards helping you achieve these goals in 2017. Happy New Year from all of us here at LIKE.TG!

The most successful product managers think of themselves as finders of pain, not finders of products. In my experience launching LIKE.TG and prior products, I’ve learned that talking early with potential customers to identify pain can lead you to create better, more innovative solutions. Although it may seem obvious, that’s not how many companies start—they often start by building a product and then later seek out problems for it to solve. It’s this “product-first” thinking that is at the core of many product failures. When the up-front pain-finding doesn’t happen, products miss the mark and can waste countless hours in development effort. Unfortunately, I’ve witnessed this first-hand. My philosophy: Find the patterns of pain first, and you’ll be able to create better products. Ultimately, what you’re seeking is a market with a consistent problem area. Then, you can obsess about that problem. Thoroughly validate it and confirm it’s a problem you can solve. Moreover, if you find that solving this pain is at the top of your customer’s priority list, you have a much better shot at creating a winning product. hbspt.cta.load(3434168, 'ad657ba8-be75-4be1-a163-e71ff5498018', {}); Finding Pain through Customer Discovery People buy products to reduce pain or create a gain. You can uncover this through customer discovery. Through customer discovery, you can learn what it would mean to a customer if you solved that problem. Your goal is to uncover the value proposition of solving problems. A value proposition represents the value that the customer gets out of using your product. So a value proposition could mean: Saving money. Saving time. Making money. Lifestyle benefits or professional benefits such as looking good in front of your boss. I believe a “product” is more than the product itself; it includes the pricing, services, the way it’s sold, and so much more. With this broad definition, you have much more room to discover frustrations that customers are facing with their current solutions or the way they’re solving problems today. My recommendation: start by speaking with at least ten prospective customers. Even at low numbers, these interviews will give you incredible insight, especially if you start hearing a consistent pattern of pain. Ask the Right Questions One of the techniques that I recommend is asking open-ended questions. Open-ended questions allow people to include more information in their answers, including how they feel, which will lead you to ask questions you hadn’t considered. “Why?” is by far the most powerful question you can ask, so ask it often. Rarely accept a customer’s initial response. By asking “why?” as a follow-up question, you can extract an enlightening answer and get to the crux of an issue. Once you find a problem to solve, it’s essential to understand how high on the priority list this falls for your prospects. An even more basic issue to understand is whether the customer is aware that they have a problem. If you need to educate customers that they have a problem in the first place, that’s a sign it could be tough to create awareness and acquire customers in the future. And if they are aware they have a problem, is the problem big enough, pervasive enough, and painful enough that someone would be willing to pay you to solve it? Do they even have the budget and the decision-making authority to purchase? If you’re solving problems that people don’t care about solving, or worse, they’re not willing to pay, then you don’t have a business model that’s going to work for your product. Pattern Recognition A lot of people think the validation of a new product is a scientific process. For instance, if you conduct 30 or 40 interviews, then somehow, you will achieve a statistically valid result that gives you the truth. But this process is subjective, and biases abound. You have to read into the nuance of what people say, and that is anything but scientific. When you conduct about 15-20 interviews, you will start to hear the same things again and again. You’ll hear patterns. So by the 21st interview, you’ll ideally hear something similar to what you’ve heard previously. However, if you do not hear a pattern of pain after a dozen interviews, then there might not be a problem to solve. There is no magic number for the right amount of interviews. However, for every additional interview you conduct, you’re incrementally lowering your risk of failure. You can conduct ten interviews and reduce your risk of failure somewhat, or 20 interviews and reduce it even further. After 90 interviews, assuming you’re asking the right questions, you can reduce your risk substantially. That is the main point of the process. Also, as I interview, I pivot my questions and the pitch along the way. So my fourth interview is nothing like my first. Once I learn where I missed the mark, I adjust and move on. This flexibility is especially true if you’re validating a solution for a domain where you have limited experience. It can be a little awkward if you’re not speaking the same language for the field. If that’s the case, you’ll learn how to phrase questions, use the right industry buzzwords, etc. How We Found Patterns of Pain at LIKE.TG At LIKE.TG, we discovered pain around the product roadmap process by initially conducting 30 interviews with product managers from a variety of companies. Most of these discussions focused on their day-to-day challenges, and the pain they were experiencing planning, prioritizing, and communicating their product roadmap. We discovered significant pain around product roadmaps. Product managers were spending hours every week on the roadmapping process, and they still weren’t able to prioritize effectively. There were disconnects communicating the roadmap with internal stakeholders. They found it hard to get alignment within their organizations and found it challenging to tie the roadmap back to strategy. We also discovered that, because they wanted their roadmap presentation to look good, they spent valuable time making their roadmap look great for stakeholders and executives. The visual aspect mattered. hbspt.cta.load(3434168, '1f74539e-d4fc-4cb3-97c6-fd86de2bf62e', {}); Based on discovering this pain, we built and launched a product that hit the pain head-on. We didn’t try to solve every problem they had but focused on reducing the pain around product roadmaps. We also created a gain by helping product managers communicate with and align their teams better. Ultimately, we help them ship better products, and we help them look good with beautiful roadmaps. We spent hours coordinating and conducting those initial interviews. By the time we launched the product, we had done over 70 interviews. But because of all of this up-front work, we got our roadmap software to market quickly, on a tight budget, and we made no significant pivots along the way. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); You can read more about finding patterns of pain and product-market fit in our book: Find Product-Market Fit Faster, Lessons for Product Managers

This post is part of a series of interviews that we are conducting with product leaders across various industries. In this interview series, product leaders share their advice with their fellow product managers. We hope this series will shed light on trends and challenges in the profession, and be helpful to new and experienced product managers alike. The following is a conversation with Chris Leckie, Product Design Director at FanDuel, a fantasy sports company. Chris has been at FanDuel for two years — or “two NFLs” as FanDuel employees would say — during which time the company has grown rapidly and implemented new processes to accommodate their distributed teams. Tweet This: “Listen to our interview with Chris Leckie of FanDuel and learn about the state of product design.” We talked to Chris about the maturation of product design as a discipline, and about how FanDuel has transitioned from employing a few siloed designers to embedding designers in their cross-functional teams. We also discussed the skills that make designers successful and some design trends we can expect to see in 2017. Listen to our full conversation and learn what Apple and Uber in have common (hint: they’ve both invested heavily in beautiful user experiences), why Amazon’s Alexa represents the next frontier in design, and much more. Also in this episode: Transitioning from a hands-on design role to a leadership role Building trust and unity when your team is distributed across the Atlantic Why friction between designers and product managers is a good thing Listen to the full interview or, if you prefer, read the transcript below. Full Interview Transcript: LIKE.TG (PP): I’m here with Chris Leckie, Product Design Direction from FanDuel. Chris, thank you so much for being here this evening and doing this interview with us. Chris Leckie (CL): No problem, it’s always my pleasure to be here. PP: Please tell us a bit about yourself and what you do at FanDuel, and give a brief overview of FanDuel. CL: I’m the Product Design Director at FanDuel — that’s traditionally taking control of the design of the products themselves, so that’s the iOS application, Android application, and web application. FanDuel is a fantasy sports company, more specifically, a daily fantasy sports company. And I’m based in the Edinburgh office in Scotland. I think what a lot of people don’t realize about FanDuel is that it was actually co-founded in Scotland before we opened up our New York headquarters. So we’re kind of split up. We have a really unique situation where engineering, product design, a little bit of UX, and project management is in our base and skull on the cross, our two offices in Edinburgh and Glasgow. And then, we have product, marketing, and UX based out of New York. We’ve got customer service in Orlando, and then we’ve got some marketing down in LA as well. So it’s really split across the board, which presents nice opportunities for travel and meeting other people, but also some unique problems that come along with that. Transatlantic relationships and just generally working together. We don’t have the ability to sit together all the time, so we have to adapt our processes a little bit. PP: Very interesting. Being from Europe myself, and living in the US, I have to ask the question: What is more popular on the FanDuel platform? Is it American football or is it European football? CL: Well, I mean, we didn’t actually even do European football until very recently. When I originally joined FanDuel, which is just coming up on two years ago, we only offered American sports, and, at that time, we’d done some market research on the possibility of launching a UK-oriented application. It’s something we’d wanted to do for a while. It’s our home turf. We’d done the American thing and we wanted to open it up a little bit. We did exactly that. We had a separate project. We did an entirely new product, instead of just working on the original code base that we had available. And we launched the EPL, which is the English Premier League, application for iOS, Android, and web in the UK. Subsequently, because we share the same sort of backend, we were able to launch EPL in the States as well. It’s still a minority sport for us. NFL is definitely like our Amazon at Christmas moment. It’s funny, you’ll find a lot of people actually identify themselves and how long they’ve worked for the company by how many NFLs they’ve experienced. So it’s like, how long have you been here? Two NFL’s. PP: Earlier you mentioned about that FanDuel is a very distributed company, and I know FanDuel has grown quite a bit over the last years. How has that growth impacted your team? In particular, the different product managers and other designers that you’re working with? What are some of the processes that you had to put in place in order to successfully collaborate with other stakeholders? CL: It’s a really interesting question. It came with its own unique set of challenges. I think anyone will attest to the fact that growing is difficult. I’m having to deal with that process. I’d like to say that everything went really nice and smoothly for us, but actually, it was quite bumpy. We grew really, really quickly, and we had to work as we were growing to set these processes in place to facilitate growth. I mean, if I use design as an example, when I joined, there were only a couple of product designers on the team. FanDuel, when they were scaling the teams, made a conscious effort to scale engineering and marketing and things like that first of all. They did that because they wanted to insure that they had a company that was able to support a larger design team. When I tell this to designers, they’re like, well, that’s not what I believe — I think you should have a really big design team. A lot of people talk about this engineering/design balance. We didn’t do that, and I think it was the right thing to do. When I joined we had this traditional view of design being this walled garden and it was quite wonderful. They would make some designs, and then they would throw it over the wall to engineering. There was no collaboration. So we knew we needed to fix this. We knew we needed to open up our processes, and this wasn’t going be an overnight fix. But we needed to get immediate things in, so we opened up a variety of different tools. We used Wake, which is effectively like a very strict version of Pinterest where designers can share everything that they’re working on. You needed to share early and you needed to share often, so everyone in the company had access to this. Immediately there was visibility into what was going on. We opened up reviews, and then we started implementing a more stream-based way of working. When I say a stream, a common similarity is with the tribes and squads model. For those that don’t know, effectively it’s a cross-discipline team that is assigned to an area of the business. For instance, we were working on, at that time, private leagues, which we call Friends Mode. It’s effectively a social way of playing on FanDuel that we never really had before. Some of the processes we put in place as well were things like design sprints, and as I mentioned, we have cross-team reviews and we have showcases. All of these things were designed to impact inclusivity and collaboration. And it’s something that we’re still working on. Our streams are getting quite big, so we’re looking at exploring splitting them into two, which is more akin to the tribes and squads model. We’re constantly working on it. I don’t think you’re ever going to have it totally perfect. We’re always willing to change based on our circumstances. PP: I’ve heard about the squad model quite a bit. Actually, we’ve covered it here on the LIKE.TG blog before. Spotify was one of the companies that really promoted the model. How many different squads do you have at FanDuel, and how many different people are part of them, and what types of job functions are part of a squad? CL: At FanDuel we call them streams, but they’re quite similar. I guess a stream would be more applicable to a tribe in the tribes and squads model. I think we have about five streams, off the top of my head, and they change. They could change quarterly, or they could change yearly, based on the company’s OKRs and what we’re trying to achieve. Our social one is probably the longest-running one, because we’re very, very committed to doubling what we started there. We have other ones centered around, for instance, a new sport. We’ve announced that we’re going to be launching golf in the product. And then we have other ones based on back-office compliance, which is a really big thing for us. States set up particular rules that we are being legislated on as a company. We need to ensure that we’re abiding by state law, so our compliance team works to ensure that we are completely compliant in every single state. And then we have some other ones. There’s native revenue, which will work on improving revenue in our native platforms. But, like I said, these can change every quarter so we need to ensure that we have processes in place to facilitate people moving about. PP: So what types of members are part of those streams? It sounds like a designer, and probably people from the development team I would assume? CL: It’s effectively a completely cross-platform team. The way I have the design team set up right now is that I have at least two designers on a stream. And the idea there is that they can work as a unit. There’s always a designer that can work with another designer and they can bounce ideas off of each other. One thing we used to have was a traditional split on mobile versus web. They would work on iOS, iPad, Android, or they would work on a web, but we’ve slowly moved away from that model. The idea now is that a designer will cover everything, so they can really rely on each other to bounce ideas back and forth without having to split up their work in any particular way. Then we have our front-end engineers, backend engineers, a business analyst, a project manager, and a product owner. So it’s effectively that kind of setup, and depending on the stream requirements, we might be more heavily loaded on one rather than the other. PP: I know that before you joined FanDuel, you were working for RightScale, an IT management B2B company. And now you’re working for FanDuel, and ultimately selling to consumers. How does design differ working for a B2B versus a B2C company, if at all? CL: In a lot of ways they’re actually very similar. At the end of the day, you’re trying to design something to accomplish a task for a particular person, an end-user. So there’s always that user-orientated process. But I think the one biggest difference is the access to users, or certainly, that’s been my experience anyway. At FanDuel, we have millions of users and we have users coming into the New York office almost every single day. That gives us a really nice forum for presenting anything we’re thinking about, or anything we’re working on, and getting early feedback. Early feedback is critical to ensuring that we’re building something that actually is for the users. We know if we’re going in the wrong direction very, very quickly. In a B2B business, what we tended to find was that people were incredibly busy, and they bought because they wanted to accomplish a task. Trying to get their time was incredibly difficult, so you didn’t always have the opportunity to speak to people that you wanted to. So, and if I use RightScale as an example, I was working on the analytics application, and we would have CFOs using it. Anything that they could give us would be really beneficial, but you can imagine how busy a CFO is. Getting that feedback was quite difficult, so you had to run on your intuition a lot more. Which was good and bad, I guess. You were more liable to make mistakes. For me, I would say that’s the biggest difference. Fundamental design is quite similar. PP: You talked about customer interviews a little bit, which I assume is probably a very important skill for a designer. If you could only pick one skill, what would you say is the most important skill for a designer to have? CL: There are a few, but if I had to pick one, I would say empathy. The ability to put yourself in the shoes of the user — and it sounds like a very simple thing to do, but proper empathy is actually quite difficult. We’re in a situation — and when I say we, I mean the populace of product managers, product owners, designers, developers, etc. — where we’re in our little bubble of understanding. We don’t actually pick up an application or website and fumble about a little bit until we understand it. Whereas your traditional end-user does. I think it’s easy to say that we can put ourselves in their shoes, and we understand that, but experience tells me that’s not the case. A really good designer is able to do that. And I think it bleeds outside of just empathy for the user’s perspective, and also into empathy for how other people in the company work — how you interact with your team members and understanding their requirements versus your requirements. PP: It sounds like there were a couple more skills that you feel are important for a designer. What were some of the other ones that came to mind when I asked that question? CL: Well, I guess as you step beyond empathy into actually trying to solve a problem, the problem-solving aspect becomes an important one. Designers aren’t just people who put a skin on things and make them pretty. They need to take an idea and put form around it, and then create an experience that is incredibly simple, even though some of these things are inherently complex. You need to ensure that you’re actually able to solve the problem. So problem-solving is a huge one. Communication, as I sort alluded to before, is important as well. And that’s not just communication when you’re doing user interviews, it’s actually communicating your ideas, communicating your work effectively, and just being able to speak to people. It’s a huge part of designing and it’s only becoming a bigger part of design as our roles start to shift and evolve. A couple of others ones might be the traditional keen eye for detail. A designer needs to be able to look at something and — it’s that sort of gut instinct — know if it looks right or wrong. This is different from personal taste because personal taste is also a big one, but your more traditional trend designers are able to look at typographic hierarchies, alignment, and these little things that you need to stay on top of if you want a really polished application. If you get those fundamentals right, it sets you up with a really nice system that will bleed throughout your products, so you need that keen eye for detail. And then the last one, it’s quite a big one as well, is the ability to take feedback. Most people don’t like getting negative feedback, but it’s a big part of a designer’s job because people have different views on what good design is. You could create something that’s actually beautiful, but someone is just not going to like it and they’re going to give you some really negative feedback, and you need to be able to take that on. You need to peck through it and decide which parts you really need to listen to and take into account — tweaks or changes or whatever you need to do to make the product better. PP: Even if you master all those skills like you do, there’s always challenges we encounter. What’s a challenge that you’ve encountered in design, and how did you overcome it? CL: Every day is a new challenge. There’s always something. I don’t think I could point to one particular challenge by itself, but if I were going pick one off the top of my head, I would probably say it was the transition from being a traditional product UI general designer, whatever title you want to put on that, into more of a leadership position. I was basically picking myself up and putting myself in a position where things were less about myself and more about the team as a whole. I was doing more management led stuff as well. I’ll be honest, some of the feedback that I got, to begin with, wasn’t great. I had to take that feedback and change the way that I would approach working with individual people. It was about taking in everyone’s feedback independently and trying to put that together as what the team wanted and then trying to set a direction around it. It’s something I think I’ve gotten a lot better at over the last couple of years. But every single day there’ll be something that crops up that I hadn’t anticipated — some demand from an area of business or some person on the team who is having a unique challenge that I’ve never ever actually dealt with before. And how I deal with that, from their perspective, and ensure that they feel like their needs are being met and they’re happy as a person and that I’m not actually having a detrimental impact on the team as a whole — it’s definitely an interesting challenge. It’s something that, when I started as a designer, I never thought that I would get satisfaction from that side of it. I always felt that I needed to be crafting something constantly. I always wanted to be designing something or involved with the team at that level. But I get a lot of satisfaction from trying to make other designers’ jobs easier. I want to remove any level of friction that they have so that they can actually just accomplish what they need to accomplish. It was a challenge to get to a level where I thought I was doing it effectively, but the payoff was nice. PP: It’s a challenge that I can personally relate to as well, and I think it is a very common challenge as one matures in their career. CL: Yeah, I guess you never really know what’s next. I mean, that’s the whole point of a challenge, right, it comes at you. I think, if I were to go back a little bit, one of the biggest things for me was when I went from a product designer to a lead to a director. I transitioned through those. One of the things that I didn’t do to begin with, that I realized more and more as time went on, was that I’d try to do too much myself. I tried to approach these problems and challenges by myself because I thought that if I accepted help, I was proving myself incapable of this role. But that wasn’t actually the case, and it was actually Rob Jones who’s the VP of Design at FanDuel, he was really good at being a forum for feedback and giving really good advice. And I probably should have done that more to the begin with, but I didn’t. You can look back and say I should have done this, but you can’t change it. PP: Was there some mentorship going on within FanDuel? Or was it just an epiphany that you had and you realized, hey I need to shift from being hands-on to being more of a lead? CL: I think there was a progression, and yeah, it definitely was mentorship. Rob had gone through it himself. He was one of the co-founders of FanDuel, so he’s seen it from the very beginning into something that is so much bigger than what it started as. I don’t think they even knew themselves how big FanDuel was going to be, or how much it was going to take off in the States. So, he got really unique experience from seeing this company bloom. I came in a bit later, obviously. He was really good at providing feedback for me. He had gone through that change — the exact same one where he was taking on more of a leadership role and he was having to deal with people more. And I don’t think I leaned on him enough to begin with because I was trying to do it all myself. But there’s no shame in accepting help and advice, which I learned. PP: For sure, but let’s talk about design some more. I’ve noticed that a very common problem is that design is subjective. It’s not unusual, if you have several stakeholders, for different opinions to be mentioned. What advice do you have for uniting stakeholders around a particular design direction, or even a particular design? And what do you do in order to get stakeholder buy-in? CL: There are a few things that you can do. Number one is to build some level of trust. You need to ensure that there’s trust in your team, and also trust that, even though sometimes you will be asked or told something that you don’t necessarily agree with, it is the right thing to do. As I mentioned, we’re broken up into streams. We’ll traditionally have a product owner, and some designers, and that stream needs to run as a unit. If there’s no trust there, you’re going to get friction. So anything that you can do to ensure that things run smoother, you should be doing it. The meaty answer is to ensure that people sit together and that they’re socializing together — that’s how you build relationships. We can’t really do that in FanDuel, and other remote teams won’t be able to do that either. We have a massive ocean between us, so we need to do it in a variety of different ways. Some of it is process-driven, which we talked about before. We decided that we were going do a few things. One of them was weekly reviews — the idea being that every single person in a stream has the ability to actually give feedback on design itself. Once a week we all get together. Now it could be that not everyone is going to attend, but there should be a representative from engineering, and a representative from QA, and a product owner and a project manager as well. So you’ve got a smattering of everyone, and design can present what it’s thinking. And then you can get the feedback from everyone. If you do that, everyone feels involved in the process. Everyone feels like they’ve had their say in what’s going on. It gives the designer a forum to actually communicate what they’re thinking and to get feedback on focused areas. It’s incredibly useful. We’ve also been building what we call a design system, which is effectively almost like a guidebook to what product design looks like at FanDuel. It explains each part. We’re having to balance our day-to-day workloads with the creation of this, so it’s not going as fast as we might like it to, but we are seeing constant progress on it. You’ll see other companies doing the same thing, as everyone seems to be talking about it right now. Companies like Airbnb have whole teams dedicated to it. We don’t have the ability to do that, but what we do is carve off a little bit, and that gives people visibility into, not just this tiny little part that they’re looking at and giving feedback on, but rather the broader thing. It’s like this holistic view of how all of this stuff stitches together. And that gives a little bit of foresight into the decisions that we make and why we make them, and it can help them give focused feedback as well. All these little things add up to a bigger picture, and people feel more involved as a whole. You’ll generally find that people are more united. PP: For sure, I think relationships built on trust is definitely key. CL: Yeah, and it takes time, and we will probably still stumble. I know we’ve stumbled, but the biggest piece of advice I could give you is, if you see a problem, deal with it head-on. Sometimes the solution to that problem isn’t one that people will like, but you need to be resolute. You need to say that this decision is being made for a particular reason, and we think it will work. You just have to commit to it. And if you do that, then I think in the long run people will be more on board with it. PP: Great advice, thank you. Chris, you have been involved with product design, in particular UX and UI design, for a number of years. Are there any common design principles that you think successful products have in common? CL: Maybe not a principle per se, but what you will tend to see with successful products is a general belief in design as a whole. And this is often aided by a co-founder being a designer, or at least a member of the co-founders having some sort of design sensibilities. If I track it back a little bit, you can always have the Apple example, right? Apple was able to sell products at a premium and offer sometimes less features than the competition, and they were able to do so because they’d invested in a beautiful product. Now, this is the same with any sort of a product-oriented company as well. You can use, for instance, Uber as an example. Part of Uber’s success isn’t that it just enables people to easily hail a cab, but also because it is such a seamless experience. They’ve invested in the experience as a whole. That’s something we are very committed to at FanDuel as well. As I mentioned, we had quite a small design team before. We’ve bulked that up, and we’re very committed now to trying to build an experience that delivers a world-class entertainment product. Yeah, so it’s not necessarily a principle… I don’t think I’ve really answered your question properly. PP: No, I think you did. If I may comment on something that I picked up on, and this really hit home because it was a revelation that I had at a conference I attended last year. Having worked most often for software companies and technology companies in my career, I feel like there is an immense focus on features and capabilities. But when I went to the conference, something that really hit home was this idea of the experience as the product. There is so much more than just the application that makes up the customer experience. It’s also how they feel based on the design, and how they interact with customer support, for example. So I think that’s definitely something that people need to keep in mind. I think that’s what successful companies do — they understand there’s more to the product than the application itself. CL: Yeah, I think you touched on a few bits there that are pretty important. I don’t want to make it sound like it’s just all about the experience. There is a balance. You could have the most beautiful experience on the planet, but if you’re not fundamentally delivering what the user wants, then you don’t have a product. And that’s the same with marketing as well. You can have the most beautiful product with all the features on the planet, but if you’re not marketing it correctly, then you don’t have the customers. You need the whole thing, which is really difficult. If I use as an example a conversation with Wilson Miner, who is a creative director — he is incredibly committed to delivering a world-class experience, and he has. Most of the best bits of Spotify and Apple Music were born out of avid exploration and commitment to the user. But, at the end of the day, Spotify steamrolled them with marketing, and just general aggressiveness. I think it’s a prime example of a company that might have actually been better, but just didn’t have all the pieces in place. PP: Yeah, that’s a good point. I mean, you have to have your bases covered for sure. CL: Yeah, absolutely. PP: Chris, you have been part of product management teams for a number of years now. I’ve seen friction between designers and product managers. Sometimes there are different goals for designers or different projects that they are working on, compared to product managers. Have you seen those frictions, and if so, how have you overcome them? What can you recommend to our listeners for improving interactions between designers and product managers? CL: I think you’re absolutely going to get friction. I don’t necessarily think friction is a bad thing. People should be opinionated if they’re truly driven and they believe in what they’re doing. They will have a strong opinion one way or another. But it’s being able to step back a little bit and question the fact of like, is my opinion really worth aggressively going after here? I think it goes back to that trust aspect that we talked about before. If you work with someone and you trust them, and they are incredibly sure of what they are pushing, then you should be able to say, look, I might not agree with what you’re saying here, but I trust you and I trust that the decision that you are making is right for either the product or the team, and I will wholeheartedly go into it. If I use RightScale as an example, we were a small team that was acquired, and we were working on an ancillary product. We had this really tight bond, and I worked with Hassan. He was in a product manager role at that time, and we had a very close relationship. I knew if he was coming to me, telling me something against what I was saying, that he was probably right. And Hassan knew that if I was calling bullshit on whatever he was saying, he was like, right, I trust you. You were hired for a particular reason, so I should trust that you’re trying to do the right thing. PP: Great answer. Like you said, it boils back down to relationships and trust. If you understand that you’re all working ultimately towards the same goal, then friction isn’t a bad thing because it means that both people are motivated and want to do the best for the product and company. CL: Yeah, everybody has goals — everyone has something that they are being held to, and there might be a revenue figure that you need to hit. Sometimes you might be more willing to take the quick route or release something that might not quite be at a level that you would be comfortable with releasing, and for me, that’s the point at which a designer or a developer has to say, I don’t think we’re doing the right thing. And that’s when you have a conversation about like, well, what is the right thing to do here? Do we delay this by a week, hoping it’s fundamentally better? Or is there really going to be that much of a detrimental impact? Do we need to get this out a little bit quicker? PP: Chris, we’ve arrived at our last question. We’re at the beginning of the year, and if you don’t mind sharing with our listeners your crystal ball — if you had to predict what we can expect this year or even in the next few years, what are some design trends that you feel pretty strongly about? CL: Absolutely. It’s interesting, I’ve got two parts to this answer because I think there’s trends in the way that the people traditionally looked at trends. And then, there’s the other part, which I think is the growth and the maturity of the product design — like the discipline and what’s next there. On your server-client traditional trends, I think we’ve hit a point now where there’s just a little bit of an evolution every single year. We transitioned to flat design. I think, piece by piece, we’ve kind of been moving back to adding depth, and sort of a physicality to interfaces. I mean the way that you look at material design, for instance, is all based on levels and cards. That’s the way that we’re looking at it as well. And what I often say to some of the designers on the team is that I like to think that you can actually just take a piece of paper and cut up your interface, and then actually be able to move around. Think about it in a physical dimension, and how does this all stitch together? And I think we’ll see a little bit more of that — it’s looking at things in more of a holistic manner. How that plays out in actual visuals, I think, is open to interpretation. We’re seeing a lot of people playing with fire because they’re bringing in more shadows and things like that. Again, we’re seeing a lot more exploration and much more rich experiences. So to be honest, it can go any way, but I think we’ll just see a subtle evolution from what we’re already seeing now. A lot of our decisions now are actually based on the operating systems that are provided to us by the likes of Google and Apple. So unless they do something completely drastic, then who knows? I guess there’s this whole augmented reality. Things sitting on the horizon with VR and whatnot which could throw things up in the air a little bit. I think that maybe leads a little bit nicely into my next point, which is the maturation of the designer’s role and what a designer should be doing. What we’re seeing is that designers are less and less just your typical pixel pushers — where you’re handed a brief and you create a flat visual, and then you throw it back and that’s it, done. I would say that 50% of your time is traditional design, and the other 50% of your time is driven around communication, documentation, working with stakeholders, and working with engineers. It’s a much more involved process. And I can only see that continuing, especially as our tooling starts to change as well. We’re seeing a lot more prototyping tools that allow us to visualize things in new ways, and that’s going to change the way that we actually approach design as a whole. And then, you bring into the blend the fact we’re actually approaching a stage where we’re having to design for things that don’t actually have a physical interface. Take, for example, Amazon Alexa — that is something that you are interfacing with. You still have this relationship with it, you still need to accomplish a task. That still requires a designer’s mindset, that empathy that I talked about before, of how do I accomplish this? And there’s nothing being created there. It’s this whole new thing. And then, you’ve got virtual reality. It doesn’t sit within the confines of what we viewed as design before. And who knows what’s next? So it’s an evolving discipline, and I think we’re gonna see that more and more over the next year and onwards, as these new territories start to evolve. PP: Yeah, I completely agree. It sounds like design will leave the screen, and go into all kinds of different devices and shapes. CL: Yeah, it’s really interesting. I mean, you have Google Home as well. It’s a little bit 2001 how it’s going to take over what’s going on, but it’s interesting to think about. We’ll eventually some sort of a voice command in every single part of the room. I’m going to use phones as an example. We traditionally have to always be willing to jump on new mediums. So we had our Apple Watch app out really, really quickly. We briefly went to smart TV stuff. We’re always willing to think about how we can use the platforms better. And it’s interesting to think about how you could actually draft your team just by walking around the house, speaking to your Amazon Alexa. Or do we investigate sort messenger chatbots, where you’re actually just speaking to something in a very human way to accomplish the same task, but without the fanciness of this interface? I think that’s gonna be a tough pill to swallow for a lot of people, because you’re not gonna have these days, months, whatever the timeline is, to craft this really beautiful visual experience, but you can craft this really nice human experience where the process is actually much nicer PP: For sure. I think it’s a really interesting time to be a product manager or a designer. There’s so much disruptive technology going on right now that there are so many new opportunities available. It’s amazing. Chris, thank you so much for your time. I really enjoyed our conservation and thank you so much for sharing your valuable advice with other product managers and designers. CL: No problem at all. I hope it was at least a little bit useful. It was good having a chat about it anyway.

Technology and design are in the midst of an exciting crossroads, where businesses are becoming aware that the products and services they provide, no matter how innovative, are competing just as much in user experience as they are in functionality. The early proliferation of dazzling consumer experiences has bred a new generation of buyers who expect even their business software to look, work, and feel the same way as the other tools and experiences they’ve come to depend on and love. Good design is good business, and over the past 5 years or so startups and established companies alike have been scrambling. Hiring a UX designer is now more important than ever to stay competitive. The problem for most companies is that, while we wouldn’t ask a product manager to hire an engineer or vice versa, these are often the groups tasked with hiring a UX designer to join the team. These groups, if being honest, may not truly understand how a UX designer will help them stay competitive, and commonly misinterpret design as simply applying a pleasing color palette or carefully selecting the right font. Businesses without an established design practice often lack the definition or understanding of design roles, leaving product development teams with a missed opportunity to incorporate design as a strategic differentiator. So, if design isn’t about aesthetics and font, then what is it? In short, good design means your user doesn’t have to think. It means the system is easy to learn, remember, and delightfully exceeds their expectations in speed and reliability. It means that every next step is carefully anticipated, building a lasting emotional connection between the user and the system that is based on trust. Great design breeds loyalty in ways your users will struggle to articulate, expressing only the sentiment that “it just gets me.” To hire successfully then, as with any position, it’s critical to focus on the outcome and not just the role. Understanding the breadth and complexity of what makes for “good design” will better position the non-designer to pinpoint the must-have qualities of a designer to join their team. Design is a Practice, Not a Function The first (and very common) mistake that businesses make in executing a strong design strategy is to focus on building the product first, with the goal of having a designer come in later to improve the user experience. But design is a practice in much the same way product management or engineering is. Having a designer come in at the end of a project to “polish” it is like hiring a product manager at the end to just work on market positioning for the product, or asking an engineer to “just hook up the back end”. It’s an all too common story for talented UX designers to be turned off from a job interview when they realize that what the company actually wants is a graphic designer. This isn’t suggesting that graphic design is somehow unimportant — it is, in fact, a hugely important aspect of a strong design strategy — rather, it’s indicative of a blatant lack of knowledge of the UX designer’s field of expertise. The misconception of “UX designer” is understandable given that it’s sometimes a heated debate even in the design community, so it makes sense that non-designers would be doubly confused. But after hours of researching the business and crafting their resume and portfolio to demonstrate how their expertise can have an impact, it can still be insulting to realize that the business didn’t even attempt to understand the role for which they had advertised. Though opinions vary, there is consensus that “user experience design” is a general term that encompasses many specific disciplines. This was made famous by Dan Saffer’s Venn Diagram, The Disciplines of User Experience Design: To simplify this and apply it to software and other digital products, think about a strong user experience design practice as one that embraces these five distinct disciplines: user research, information architecture, interaction design, visual design, and UI engineering. This illustration outlines each discipline accompanied by its various tools and deliverables. For the non-designer, it’s not necessary to have an in-depth understanding of each UX discipline. But it is necessary to have some awareness of these disciplines to best inform what to look for when hiring to establish a design practice. The first designer or UX agency you hire on the team will be critical to this evolution, so it’s important to invest in someone whose expertise covers a wide gamut of these disciplines. And as the business grows, so should the design practice. Use the scale of UX disciplines to round out the talents of a growing UX team to ensure the right emphasis in the areas that will help great design be a strategic differentiator for your business. 5 Qualities to Look for When Hiring a UX Designer: To ignite a strong design strategy for your business, your first design hire should be able partner with you to own and execute that strategy. Assuming you only have budget for one designer, then it’s also important that this person has the experience and portfolio that demonstrates their strengths as an individual contributor. Following are five qualities of a designer who can make an immediate impact as well as nurture the growth of a solid design practice for your business. Glutton for Empathy Any designer’s core skill is their ability to empathize with users so they can anticipate their expected interactions with the product. But great designers understand that, while their work focuses primarily on the end user as the consumer, engineers and product managers are also consumers of their user insights. So, designers’ ability to empathize and distill information into meaningful and relatable stories extends beyond the interface design all the way down to building relationships and trust within the teams they are supporting. Business and Strategic Thinker In some ways, your first designer should be indistinguishable from a product manager in the way they approach problem discovery. A good design leader understands how to prioritize user needs with business goals and can balance the natural tension between the business, technology, and the user. Oftentimes the role of balancing user vs. business needs falls on the shoulders of the product manager, and in a tough spot it’s usually the business that wins. But a great designer is eager to forge a partnership with their product manager and engineering leads, freeing each other up to lean on their individual biases to allow healthy debate and more rounded decision-making. Teacher and Facilitator Designers want to be respected for their unique craft, but great design leaders refuse to hoard their design skills and won’t be protective or territorial about the process or their design team. Great UX designers are eager to teach and share in their craft, and they will often do this through the evangelism of design thinking. In practice, you’ll know you have a great designer in place when they are facilitating design workshops with engineers, or if they simply roll a whiteboard up to their team and hand the marker to an engineer and ask him or her to sketch an idea. To learn more about tools experts use in product design teams, watch this recent webinar: 点击播放声音 @keyframes VOLUME_SMALL_WAVE_FLASH { 0% { opacity: 0; } 33% { opacity: 1; } 66% { opacity: 1; } 100% { opacity: 0; } } @keyframes VOLUME_LARGE_WAVE_FLASH { 0% { opacity: 0; } 33% { opacity: 1; } 66% { opacity: 1; } 100% { opacity: 0; } } .volume__small-wave { animation: VOLUME_SMALL_WAVE_FLASH 2s infinite; opacity: 0; } .volume__large-wave { animation: VOLUME_LARGE_WAVE_FLASH 2s infinite .3s; opacity: 0; } 55:49●●●●●●●AgendaBackgroundTeam StructureDesign ProcessArtifactsProduct ComparisonLive Q&A #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset{font-size:14px;} #wistia_chrome_23 #wistia_grid_75_wrapper div.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper span.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper ul.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper li.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper label.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper fieldset.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper button.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper img.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper a.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper svg.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper p.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper a.w-css-reset{border:0;} #wistia_chrome_23 #wistia_grid_75_wrapper h1.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:2em;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper h2.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:1.5em;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper h3.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:1.17em;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper p.w-css-reset{margin:1.4em 0;} #wistia_chrome_23 #wistia_grid_75_wrapper a.w-css-reset{display:inline;} #wistia_chrome_23 #wistia_grid_75_wrapper span.w-css-reset{display:inline;} #wistia_chrome_23 #wistia_grid_75_wrapper svg.w-css-reset{display:inline;} #wistia_chrome_23 #wistia_grid_75_wrapper ul.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased;list-style-type:none} #wistia_chrome_23 #wistia_grid_75_wrapper ol.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased;list-style-type:none} #wistia_chrome_23 #wistia_grid_75_wrapper li.w-css-reset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased;list-style-type:none} #wistia_chrome_23 #wistia_grid_75_wrapper ul:before.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper ol:before.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper li:before.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper ul:after.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper ol:after.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper li:after.w-css-reset{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper label.w-css-reset{background-attachment:scroll;background-color:transparent;background-image:none;background-position:0 0;background-repeat:no-repeat;background-size:100% 100%;float:none;outline:none} #wistia_chrome_23 #wistia_grid_75_wrapper button.w-css-reset{background-attachment:scroll;background-color:transparent;background-image:none;background-position:0 0;background-repeat:no-repeat;background-size:100% 100%;border:0;border-radius:0;outline:none;position:static} #wistia_chrome_23 #wistia_grid_75_wrapper img.w-css-reset{border:0;display:inline-block;vertical-align:top;border-radius:0;outline:none;position:static} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset button::-moz-focus-inner{border: 0;} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree {font-size:14px;} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree div{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree span{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree ul{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree li{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree label{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree fieldset{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree button{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree img{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree a{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree svg{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree p{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree a{border:0;} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree h1{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:2em;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree h2{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:1.5em;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree h3{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:1.17em;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree p{margin:1.4em 0;} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree a{display:inline;} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree span{display:inline;} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree svg{display:inline;} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree ul{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased;list-style-type:none} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree ol{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased;list-style-type:none} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree li{box-sizing:inherit;box-shadow:none;color:inherit;display:block;float:none;font:inherit;font-family:inherit;font-style:normal;font-weight:normal;font-size:inherit;letter-spacing:0;line-height:inherit;margin:0;max-height:none;max-width:none;min-height:0;min-width:0;padding:0;position:static;text-decoration:none;text-transform:none;text-shadow:none;transition:none;word-wrap:normal;-webkit-tap-highlight-color:rgba(0,0,0,0);-webkit-user-select:none;-webkit-font-smoothing:antialiased;list-style-type:none} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree ul:before{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree ol:before{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree li:before{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree ul:after{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree ol:after{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree li:after{display:none} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree label{background-attachment:scroll;background-color:transparent;background-image:none;background-position:0 0;background-repeat:no-repeat;background-size:100% 100%;float:none;outline:none} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree button{background-attachment:scroll;background-color:transparent;background-image:none;background-position:0 0;background-repeat:no-repeat;background-size:100% 100%;border:0;border-radius:0;outline:none;position:static} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree img{border:0;display:inline-block;vertical-align:top;border-radius:0;outline:none;position:static} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-tree button::-moz-focus-inner{border: 0;} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-max-width-none-important{max-width:none!important} #wistia_chrome_23 #wistia_grid_75_wrapper .w-css-reset-button-important{border-radius:0!important;color:#fff!important;} Continue WatchingFirst Name*Last Name*Job Title*Email*LIKE.TG is committed to protecting and respecting your privacy, and we’ll only use your personal information to administer your account and to provide the products and services you requested from us. From time to time, we would like to contact you about our products and services, as well as other content that may be of interest to you. If you consent to us contacting you for this purpose, please tick below to say how you would like us to contact you:I agree to receive other communications from ProductPlan.In order to provide you the content requested, we need to store and process your personal data. If you consent to us storing your personal data for this purpose, please tick the checkbox below.I agree to allow LIKE.TG to store and process my personal data.*You may unsubscribe from these communications at any time. For more information on how to unsubscribe, our privacy practices, and how we are committed to protecting and respecting your privacy, please review our Privacy Policy.#wistia_grid_75_wrapper{-moz-box-sizing:content-box;-webkit-box-sizing:content-box;box-sizing:content-box;font-family:Arial,sans-serif;font-size:14px;height:100%;position:relative;text-align:left;width:100%;} #wistia_grid_75_wrapper *{-moz-box-sizing:content-box;-webkit-box-sizing:content-box;box-sizing:content-box;} #wistia_grid_75_above{position:relative;} #wistia_grid_75_main{display:block;height:100%;position:relative;} #wistia_grid_75_behind{height:100%;left:0;position:absolute;top:0;width:100%;} #wistia_grid_75_center{height:100%;overflow:hidden;position:relative;width:100%;} #wistia_grid_75_front{display:none;height:100%;left:0;position:absolute;top:0;width:100%;} #wistia_grid_75_top_inside{position:absolute;left:0;top:0;width:100%;} #wistia_grid_75_top{width:100%;position:absolute;bottom:0;left:0;} #wistia_grid_75_bottom_inside{position:absolute;left:0;bottom:0;width:100%;} #wistia_grid_75_bottom{width:100%;position:absolute;top:0;left:0;} #wistia_grid_75_left_inside{height:100%;position:absolute;left:0;top:0;} #wistia_grid_75_left{height:100%;position:absolute;right:0;top:0;} #wistia_grid_75_right_inside{height:100%;right:0;position:absolute;top:0;} #wistia_grid_75_right{height:100%;left:0;position:absolute;top:0;} #wistia_grid_75_below{position:relative;} Strong User Researcher It’s not uncommon for designers to be a little rough around the edges when it comes to user research. Some designers, while they can design a beautiful screen layout, struggle to design structured research such as feedback loops, surveys, and usability tests without being influenced by their own bias to the design. A strong design leader can separate their ego from the raw user feedback because they are more driven by getting it right for the customer than receiving personal validation on their designs. They also put their facilitation skills to work in their research by making it a collaborative effort and inviting engineering and product management to learn through observation of usability tests and participation in qualitative interviews. Student of Agile/Lean UX The toughest spot a designer may find themselves in is as a bottleneck to their team’s ability to make fast decisions and move forward quickly. A designer’s empathic connection to the customer innately causes a sort of fear of lasting negative first impressions about a product or feature that is still a work-in-progress. This fear can be hugely detrimental to the team if their work isn’t being constantly validated with end users. But the fear can be hugely beneficial if leveraged to help teams think strategically about how to collect feedback and iterate in a way that will create lasting positive first impressions from customers. It’s important that the first designer you hire has the experience to put their fear in check and use it to encourage thoughtful iterations and smart rollout plans to achieve the desired results. Download How Agile Product Managers Can Build Better Products ➜ hbspt.cta.load(3434168, 'b4eb5c0b-bf4b-4a7e-9b0a-75f92005c127', {}); A Lasting Design Strategy A strong design strategy begins with an understanding of the impact and outcome of great design, and puts the right talent in place in order to reach that outcome. To achieve this, the non-designer must first be humble enough to admit that they might not fully understand value and role of a designer, then be diligent in learning more about the craft for which they’ve been charged with hiring for. By investing in hiring a UX designer with an acumen for business, this first hire can act as a partner to establish a healthy design practice for the long term. The role of design transcends what looks good and builds and emotional connection to the end user because it also feels good to use the product. A business’ ability to leverage design to tap into the latent needs of its users is what will drives loyalty, and leaves competitors scratching their heads. J.J. Kercher shares more of her product and design leadership thoughts in Spotlights: J.J. Kercher “Return focus back to the customer and product”, below.

This post is part of a series of interviews that we are conducting with product leaders across various industries. In this interview series, product leaders share their advice with their fellow product managers. We hope this series will shed light on trends and challenges in the profession, and be helpful to new and experienced product managers alike. The following is a conversation with Julie Cabinaw, VP of Sales, Marketing & Innovation at Scentsy (a leading provider of home and personal fragrance). Before Scentsy, Julie held a variety of product management and user experience roles at Microsoft, Healthwise, Hewlett-Packard, and Amazon. Here is Julie’s story. You have been involved in bringing new products to market for quite some time. How has product management changed over the years? Julie Cabinaw (JC): Thinking back to the early stages of product management, I remember really trying to convince developers that we had value to add to the equation. In the late 90s, developers often drove the vision for products — and it was based quite a bit on what technology could do. Sometimes, user specific needs were secondary. I think we’ve really seen a maturation of product management’s relationship with all the other parts of the company. We’re working with sales, we’re working with marketing, and we work so closely with technology. We really exist as a unifying force to be the voice of the customer. We help make sure that customer experience — or in our case at Scentsy, consultant and customer experience — is the center of what we’re doing. As product managers, we’re relied upon to be the voice of business, consultant and customer needs, and to rationalize these sometimes conflicting viewpoints. The maturation of the product management field has been really fun to be a part of. Tweet This: “Product Managers need to be the voice of business and customer needs, and to rationalize conflicting viewpoints.” You worked in a variety of product-related roles over the years, including UX positions at Hewlett Packard and Healthwise as well as leading the content experience team for the Amazon Kindle. What’s the biggest product design challenge you’ve encountered in your career and how did you solve it? JC: There have been so many fun challenges to work on over the years. I have two examples. One is from the healthcare space. In healthcare, people have struggled with the role of technology — knowing that it could be absolutely essential to improving people’s decision-making relative to their health issues, but also not wanting to over-complicate things for patients and families. One very user-focused challenge that we had at Healthwise, a Boise-based health decision-focused company, was helping people make better health decisions. We had to understand where patients were in their thinking about their healthcare issues. The challenge was understanding what was important to them, and then combining that information with what we knew about the patient transactionally (maybe their claims history or patterns in data that might predict that they have more health issues with a particular concern) — as well as what the best medical guidance might be. It was an incredibly big product design challenge and it continues to be something that’s very near and dear to my heart. The folks at Healthwise do amazing work in researching the needs of patients and representing those through content technology. I think that’s probably one of the proudest things: being part of something that really made a difference through technology. That ability to make an impact, and improve someone’s life is a similarity to the product management function at Scentsy. It’s so exciting! On the other hand, the scale of working on content experience at Amazon is fascinating — being able to understand the magnitude of a project that has so many technology implications. There are so many different versions of the Kindle that you have to take into account in order to roll-out a new feature. When you think about people using their Kindles, many people still love the first Kindle that they ever purchased. And so, when making decisions about how far back to go on a feature set, you have to understand how that experience is going to play out for millions of users around the world with different languages and with different expectations from a user experience standpoint. It was an amazing thing to watch happen at a company like Amazon. The efficiency and the scale that they bring to it, while still being laser-focused on the customer, was really fun to learn from. You are currently the VP of Marketing & Sales Technology for Scentsy. What are your recommendations for how product and sales and marketing teams can work better together? JC: What’s most important, I think, is bringing together a cross-functional team for an opportunity to share a vision. People who are involved in a project early on, from the beginning, should be able to represent their viewpoints and answer tough questions. We try to do a lot of design thinking in the technology program work that we do at Scentsy. We broaden and explore different problem spaces before we narrow in on a solution. This approach has two advantages. One is creating the best possible product. And second, more to your question of how to bring teams together, it focuses everyone on understanding that what we’re about to do is bigger than us — bigger than any of our particular interests on our team. It’s really important to keep the focus on the problem that we’re solving and the people that we’re solving it for. Another thing that’s important is being a good listener. I think sometimes people listen for the things that validate what they already want to do. It’s so much more important to listen openly and make sure you’re getting a complete understanding of how someone thinks about things, what they’re looking for, and what they’re concerned about. At Scentsy, we’re exploring a partnership between our hard goods product team and our technical product team. It’s really interesting to, for the first time, bring together these teams that have never worked with each other, but that have similar backgrounds in many ways in terms of being owners of their products. In bringing them together we really get the best of both worlds — and listening goes a long way in that. Tweet This: “Data provides a strong foundation for everybody to understand the problem in a similar way.” I think the other thing that really helps when you’re talking about needing to reduce friction between teams is making sure that people understand things from a data-focused perspective. There’s always a balance of guts (intuition) and data that goes into the things that we do, but data provides an incredibly strong foundation for everybody to understand the problem in a similar way. Having everybody sit and watch users struggle with something, or succeed fabulously, gives everybody a shared understanding of how things are going. It’s crucial to get everybody grounded in reality through data, rather than just their impressions or their opinions of what might be the best path. And finally, I think good processes are really important to have when you’re working together. The larger a company is, the more some kind of process is needed to make sure that things don’t get missed, and that you don’t miss out on opportunities to understand each other’s perspectives. Given your extensive UX experience, are there any design principles that you think successful products have in common? JC: Foremost, I think great products are designed based on user needs. We see a lot of great technology, and we think of potential applications for that technology, but being grounded in the most important problems that users are trying to solve is not so much an aesthetic design principle, but a principle that keeps everybody focused on what they’re really trying to accomplish. The next thing that we’re always looking for is simplicity in design. There’s a lot of things we can do with any particular product, but should we do them? Should we do them now? I think everybody gets very focused on a long-term vision for what something will be in the future. A lot of companies I’m seeing are maturing to a state of understanding the concept of an MVP, and getting comfortable with continual iterations and cycles to improve on that. I think that continuous deployment and having regular ongoing releases allows us much more technical agility. Bridging from UX to product management, as late as five years ago, it seemed that every product manager’s fear was not getting to come back anytime soon to what they just released and improve upon it. You felt like you needed to cram in as much as you could in that first release, and it may not have been the quality that you wanted it to be. So improvements in the way that we deploy things technically have really allowed us to have more simple MVPs. And then, minimalistic design is kind of the companion to simplicity in feature sets — ensuring that the design keeps the focus on the most important next action that a user can take. Minimalism is so important when you’re trying to accomplish a brand experience, and when you’re trying to realize the goal of having someone buy something or complete a task. Minimalism is often hard. It’s much harder to develop something and scale it back to the most essential than to just kind of throw it all out there and hope for the best. It requires a lot more discipline to achieve minimalistic design. Finally, exploring the gaps in what is not said by users, to understand unmet needs and create a product that perhaps a user couldn’t have articulated that they wanted, but delights them in providing new solutions they had not anticipated. What advice do you have for uniting stakeholders around product strategy and getting buy-in on the roadmap? JC: I’ve had the chance to hone this skill over many years, but I think some of the best lessons that I learned have come in the past couple of years, both here at Scentsy as well as at Amazon. There are a lot of articles around Amazon’s working backwards process. I encourage people to explore the Amazon process. The idea is to unite your stakeholders around a shared vision of customer experience. The process involves writing the press release, a crisp and succinct six page strategy, answering hard questions about the approach via FAQs and committing to disciplined and rigorous document reviews. Working backwards allows the rest of the project to flow in a much nicer way. We make sure that we understand how we’re going to measure success, and we make sure that we can think of any possible question that a user could have or any scenario that could develop that we would need to address. It’s something that I’ve brought into my work currently, and I think we’re having higher quality and better releases as a result of more rigor upfront. Not everyone was super excited at first, with a more rigorous approach. Then I had one of my team members, after having gone through the process, reach the C-level review for the program that she was proposing. She was able to answer every single question that got fired at her, and to get approval for a very ambitious sales technology program. Tweet This: “First and foremost, you need to unite everyone around a shared product vision.” So, first and foremost, you need to unite everyone around a shared vision and get them bought-in on the story. Then, follow up with strong evidence for the KPIs that you’re trying to achieve. You need to be able to show that you’ve done your homework in regard to the return on investment that your product will produce. And even if you don’t have the perfect scenario, working with your partners in sales and in finance to build a model based on logical assumptions is the really big part of the battle. Finally, for resolving differences of opinion around experiential issues, bringing in user feedback and data is really essential. You need to show that you’ve arrived at your recommendations based on real user input. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); How do you incorporate customer feedback into your roadmap? JC: One of the most important things, and something that I’ve done at the last couple of organizations that I’ve been a part of, is making sure product management is unified with UX. They should have such a tight alliance that there’s just a natural understanding among the team that customer feedback has a role in every phase that they move through — whether that’s researching the initial idea for a concept, getting feedback on prototypes, or the Wizard of Oz-type things where we’re simulating a product’s experience and understanding reactions to it. Right now we’re in a thousand person beta for a new product. We uncovered a fairly significant issue and we’re excited that we encountered that issue with 1,000 people rather than 130,000 people. It helps you understand things so much better once you get the the product out into the wild. When we release something out to our consultants and our customers, we have several mechanisms to evaluate it. We’re using A/B testing. We’re using on-site surveys for new features, and we’re doing ongoing usability testing of both existing features and new features that are being planned. Any given week we’re probably running at least three or four usability tests on things in different phases of the cycle. For us, feedback is an incredibly big part of what drives our roadmap. It helps drive the next set of features, and course-correct features we may have planned but that need to be tweaked. What are some big mistakes that you’ve seen product managers make (or mistakes you’ve made yourself)? JC: I am going to speak from personal experience, but I have seen other product managers do this too. I think when you’re younger, you want so much to be the hero of the product, and you care deeply about your product. But what can happen is that you take too much on yourself, and you don’t realize the value that other people can bring to the table. You think you have to do it all yourself. You’re not inclusive enough, and in the end, you don’t create a product that is good as you could have created, had you allowed those people to be a part of it. It’s often a matter of ego. You say to yourself, “I know what the right thing is. I’ve got the data. Thank you for your opinion, but I’ve got it.” I think that this is especially common when you’re newer and you’re trying to prove to people that you know what you’re doing. What ends up happening is that you prove you can build something pretty good all by yourself, but you could have created something much bigger and much better if you had some other input. Tweet This: “There is a balance of head and heart in any good product manager.” Another mistake is not understanding that there is a balance of head and heart in any good product manager. Every single situation involves a mix in some way of those two parts. You have to have that foundation of data and analytics to make decisions, but sometimes product managers who don’t appreciate the heart, or the personal impact of a product design choice, may miss opportunities to put in little kisses that move a product from being a good utilitarian experience to something that people talk about. Finally, another common mistake I see product managers make is having a big vision, but not realizing how much scenario planning they need to do in order to achieve it. You can’t afford to gloss over the details. You may, for example, realize that there’s a gap in a feature set that you need to release. This means you’re either going to delay your product, or you’re going to release something that’s not as good as it should be because you’re missing a big part of it. This relates back to the first point about making sure you have enough voices in the mix giving you feedback and helping you make better decisions. But it’s also about playing devil’s advocate with yourself and with your team — asking, “What’s the worst thing that could happen here? What’s the best thing that could happen here? If the best thing happens, do we have enough bandwidth to handle what’s going to come at us?” What do you think are the most important skills for product managers? JC: What I’ve learned over the years is that there is an expectation that good product managers have a basis of technical and business acumen. They should functionally know how to write requirements and how to communicate with developers. They should understand how to build a business case from a financial perspective. Those things are kind of a given, in my opinion. When I’m hiring someone new, the things that I’m looking for most are the things that I’ve realized over the years result in better members of my team. The most important thing is passion. You can see that light in some people’s eyes where they just get so fired up; I call it the raw meat factor. You can just feel from everything that they’re doing that they’re going to go after what they’re about with 110%. On the other hand, you may have somebody who’s like, “Yeah, I’m really good at what I do, but it’s just a job.” Those can also be good people to have on your team, and you need a balance of all sorts of people. But with product managers, I’m looking for a spark. And, along with a spark, intense curiosity. In good product management teams, people ask questions about each other’s work. To some it might appear aggressive, but it actually results in people thinking harder about what it is that they’re doing. Done respectfully, intense curiosity can lead to figuring out the root cause of why you’re making a decision, or why users might be feeling a certain way, or why something’s going on with the analytics on your site. It’s all about not just taking things at face value, and trying to understand the “why”. Finally, the last two features I look for are soft skills. Every new market that you might be in — you have to be fluid and teachable, and agile. We’re not looking for someone who won’t make mistakes, we’re looking for people who are willing to make mistakes, but won’t make the same mistakes twice. You also, I think, have to be willing to have a chameleon-like aspect of yourself. It’s not that you don’t keep your core values or your core skills, but you should understand how to soak up the environment and the context of a company. You should be able to build relationships and understand the factors that drive people in the company to make decisions, and understand how to meet their needs. I think those things — passion, curiosity, teachability, having chameleon-like aspects, and the softer relationship management skills — go a long way. But they need to be built on a base of technical acumen and business strength.

This post is part of our product lessons learned series of interviews that we are conducting with product leaders across various industries. In this interview series, product leaders share their advice with their fellow product managers. We hope this series will shed light on trends and challenges in the profession, and be helpful to new and experienced product managers alike. The following is a conversation with Lea Hickman, VP of Product Management at InVision (an award-winning SaaS-based product design collaboration platform). Lea is a tech industry veteran and before leading the product team at InVision, she was an executive at Adobe, AOL, and Netscape. Here is Lea’s story. 1. How has product management changed over the years? Lea Hickman (LH): I think the fundamental catalyst to changing product management over the years has been the change in development processes. We are no longer in a world where we create 70-page PRDs and product specs to hand off to engineering. The advent of agile and lean development methodologies, it’s fundamentally changed the work a product manager does. Not only from a task perspective but also the type of skills that are required. I remember early on in my career, product management was more like project management. It was someone who was part project manager, part systems analyst — where you were writing very detailed specifications. And thankfully, that has evolved into something where a product manager is more like a mini-CEO. Someone who can understand holistically what the problems really are, identify if they’re big enough problems to go after, and work with a core team to find the most efficient way(s) to solve them. Here at InVision, we look for a very specific type of product manager. Our company solves workflow problems for design teams, so our product managers usually have a design background. The other key criteria are that they are very entrepreneurial. We typically look for folks who have founded or started their own companies. This provides the mindset of someone who is willing to play the mini-CEO role. That person who’s willing to jump in and be a critical thinker and a great problem solver (coupled with design skills). If they have those two fundamental skills, that’s the recipe for our success on the product management side at InVision. Anything else, we can teach. 2. What’s the biggest product design challenge you’ve encountered in your career and how did you solve it? LH: Throughout my career, the biggest challenge is probably when the iPad was first released. The iPad was introduced when I was at Adobe and we were looking to understand how users design on a tablet device. How would they naturally and intuitively think about creating design on a tablet? This was a completely different way of consuming information. We wondered, how could it be used to create content as well? The design challenge was focused on a different form factor. You have this device that has a camera attached to it and a completely different interface — touch. We spent a fair amount of time exploring ways to make that even better and to leverage the device. Our CTO at the time was Kevin Lynch who firmly believed there was a great opportunity there. We did a lot of investigation and a lot of discovery work to understand how we could meet that need. We launched a few iPad products that did quite well and got a lot of adoption. In fact, the artwork behind me (and I know no one’s going to be able to see it) is an album cover that was created by a designer named Brian Yap, who used one of our tablet applications to do the illustration work. I’m not entirely sure we solved it during that time frame — I’m not sure it’s solved today, but I think it’s a very interesting challenge, in terms of how we can leverage different platforms to create content. There’s promise and an audience for it, but I think designers need the power and precision of a more robust environment. That was the big takeaway. 3. You led the charge when Adobe Creative Suite transitioned to a subscription-based model. Do you have any recommendations for product managers on how they can best navigate big shifts in strategy? LH: On that particular project, especially considering the scale of it (hundreds and hundreds of people were involved), consistent and repetitive communication was absolutely critical, both verbally and written. I can’t emphasize that enough. A product manager has to be obsessive about getting their story out and repeating it. Never assume that just because you already told someone, they’re going to remember what the story is, or the why behind making a pivot. That was a huge takeaway. Over-communicate, make it extremely consistent, and do it again and again and again. Also, be sure to pre-vet key messages with your stakeholders — which is essential for making any major strategic shift. If you have an idea of how you want to shift something, meet with your stakeholders ahead of time and get their feedback prior to actually doing that broader communication. 4. What advice do you have for uniting stakeholders around product strategy and getting buy-in on the roadmap? LH: I always make sure that whenever there’s a roadmap discussion, no one in the room is seeing the roadmap for the first time in that forum. I’ve had the most resistance from stakeholders when they were surprised by something. Now, I take whatever draft I have, and I share it really early on, like prototyping. If you present your ideas and thoughts and start gathering feedback to course correct them from the beginning, you’ll earn your stakeholders’ trust since they will buy into the process with you. Then, take your early concepts, pre-vet them again with your stakeholders, and ask them for help to refine and shape. This doesn’t mean you’re asking for their ideas, you’re collaborating and bringing them along in the process. Nine times out of 10, this strategy will alleviate major conflicts you’ll face when you have the official roadmap discussion or the official MVP discussion. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); 5. What do you think are the most important skills for product managers? Tweet This: “A great product manager believes in what they’re creating, and has conviction around their ideas.” LH: There are three traits I look for in product managers: Product managers need to be exceptional communicators. The more subtle, harder thing to interview for is conviction. A great product manager believes in what they’re creating and has conviction around their ideas. And by that, I don’t mean falling in love with your idea. I mean having a defensible conviction about your idea and being able to stand behind it and answer the ‘why’. I talk a lot about the why. We often fall short in explaining the why to other people, and that’s part of the conviction. If you can explain why you want to do something, you have conviction. The final trait is something that’s important for me when I’m hiring and in product managers, I like to work with — a sense of humility. Understanding it’s not about you. It’s about getting an opportunity to shop for the product and get it into the hands of users — letting users decide. 6. Are there any design principles you think successful products have in common? LH: It’s research — but it’s not the UX type of research most folks talk about. We do research a little differently at InVision. We recently invested in and hired our second ethnographic researcher, who evaluates people and cultures. I like this approach because if you can get at the root cause of a problem through research, you’ll come up with an ultimate solution. For example, we work with a lot of companies (big and small) who have really incredible design teams (Airbnb, WeWork, IDEO, Adobe). If we present a proposal or review a prototype for a new feature, we’re going to have a very short conversation with that team, where it’s just about the solution we’re putting in front of them. However, if we go in and observe how the team works, and we sit with them for a while, we begin to understand their problems. One of our ethnographers has a Ph.D. in anthropology and sits with a few design teams a week. Through his observations, we’re able to get at the root cause of the problems particular design teams are having. It helps us to ask, “Is this a one-off problem or is this a persistent problem? How many people are having this problem?” This is step two of our research. You’re basically sizing your market. Then, go into product discovery, which identifies solutions that address the root cause. When we think about design, we start at the root cause of the problem. Tweet This: “When we think about design, we start at the root cause of the problem.” Then listening to customers, observing them, and applying solutions, followed by UX testing and analysis, which determines the solution that will best meet those needs and address those core problems we’ve uncovered. It’s so foundational, giving you something you can build on and iterate on that yields great results. 7. What are some of the challenges that UX/UI teams have working together with Product Management? And what do you recommend to improve their interactions? LH: At InVision, we have this concept of a core team, which consists of three roles: the product manager, the design lead, and the development lead. The core team goes through all of that product discovery we talked about earlier. We found this process creates a lot of empathy across the roles and eliminates a lot of friction, particularly between the product manager and the UX or UI designer. From a velocity perspective, it cuts a lot of that friction out too. It helps these teams understand whether or not a particular design is going to be the most efficient to implement in real-time. It allows the team to coalesce around that core MVP in terms of what it’s delivering. You don’t have a PM saying, “I need feature x by y date,” and then a designer creating things that are unimplementable and a developer saying, “Wait a minute, I have a say in this too…” I’m a very strong believer that great ideas come from everywhere — design, development, or product. As soon as you take that away, it removes a lot of that friction. 8. What are some major product design trends that we can expect in 2017? LH: It’s not so much about a design trend, but about designer trends. I’m finding a lot of the lines are blurring across the product team. Similar to when I was talking earlier about how we put our product teams together. Tweet This: “I think it’s not so much about a design trend, but it’s about designer trend.” More and more designers are learning how to code, and product managers are learning how to design. The whole core mix of how we built products in the past and how we’re going to be building products in the future is evolving. To learn these languages, the tools are making design so much easier. Everything is evolving so quickly, where before you needed to have very specific skill sets. The biggest trend is the explosion—the simplification of the tooling is going to make anything possible.

This is the first in a series of interviews that we’ll be conducting with product managers across various industries. We’re curious to hear about how they got into product management and about their experiences on the job. We hope this series will shed light on trends and challenges in the profession, and be helpful to new and experienced product managers alike. Our first conversation is with Ronnie Regev, an experienced product manager at AppFolio (a California-based SaaS company that builds software for property managers). Here’s Ronnie’s story. How did you get into product management? Ronnie Regev (RR): Like many product managers, my route to the role was long and indirect. There aren’t a whole lot of people who finish school and end up in product management right away. Most people come into it from something else — and in my case, I spent about eight years working in infrastructure and operations in the video game industry. It was a very interesting job and it was very technical. But I grew increasingly frustrated with being on the receiving end of business decisions that were made really far away from my team. Inevitably, my team would have to solve problems that we weren’t involved in identifying or qualifying. Also, because we were in a back-end type of role, it was difficult to see how the work we were doing was directly contributing to the success of the company. Over the course of several years, I started to take on a bit of that frustrated mindset. It never affected my work, and I was still really happy in my job, but at a certain point, I decided to leave the company. I had been working there for a long time and I wanted to do something a little bit different. As I started interviewing for other IT infrastructure operations leadership roles, I realized that I actually wanted to try something else. Through a friend, I was introduced to the director of product management at RightScale, who told me that I might find product management interesting. I had a pretty open mind. I was starting to figure out what I didn’t want to do, but I still needed to figure out what I wanted to do. I thought, “Well, product management, I don’t really know very much about this. It’s just a conversation. Let’s see how it goes.” What seemed really appealing to me about RightScale was that I’d be able to use my subject matter knowledge — my understanding of systems engineering and infrastructure and scalable web systems in a new, more challenging and satisfying way. I’d be speaking to people who used systems like the ones I was used to using, understanding their challenges and then working with engineers and designers to actually build software that solved their problems. I didn’t even realize that was a job — something that somebody would be willing to pay me to do. When I put everything together, I thought, “Wow this seems like such an appealing idea.” I’d get to use my historical knowledge and my interest in speaking to people about what’s difficult for them to inform how software gets developed. And I’d get to to be hands on with a technical team. Product management is not purely a marketing-facing type of role — there’s still this technical aspect of it which was appealing to me with my career background. That was my path into product management. I happened to meet the right person at the right time, and it clicked for me. I met the director of product management at RightScale, who was able to identify that I had whatever intangible qualities a product manager should have and gave me a chance in the role. After two years at RightScale I moved on to AppFolio for a new opportunity and, over four years later, I’m still happy a Product Manager. What do you love about your job and what’s challenging? RR: What I love about the job and what’s challenging about it are sometimes the same thing. I love that point in time when we’re about to release a new feature or a new product to our customers. There’s this nervous excitement that my team has. It’s a really special time because it’s the result of a lot of hard work, and maybe also some frustration and arguments. Another reason for excitement around a feature release is the anticipation of user feedback and usage data. We may be confident in the choices made but qualitative and quantitative feedback is the proof! Once we get that proof it reinforces the positive impact on our customers’ business and AppFolio’s as well; exactly the kind of career choice validation I sought! A lot goes into that moment when we’re about to release something — a lot of individual opinions and insights from our customers. And it doesn’t necessarily have to be a big new feature or a big new product. We could be releasing something really small — in which case, the excitement is based on challenging our own assumptions and assertions. Tweet This: “Always question your assumptions.” #ProductLessons Another thing I love is collaborating with the teams that I’ve been fortunate enough to work with — QA engineers, designers, and software developers who are really interested in solving problems and invested in understanding the context we’re working in. Being part of these teams has been a fantastic privilege and it makes work so much fun. As for the things that are hard, I’d say combating my own biases is challenging. Like anyone else, I have my assumptions about what’s most valuable for our business, what’s most valuable for our customers, what the best path is in solving a particular problem. The hardest thing is to extract myself from those assumptions and overtly challenge them. But that also kind of falls in line with the things that I love about my job, because I consistently learn about myself, product development, our customers, etc… Another thing that’s really difficult is always maintaining a focus on customer value. It’s easy to start thinking that we should do something because we’ll make more money — or because maybe we think we can grow adoption or satisfy an internal stakeholder. But at the end of the day, we should be focusing on delivering value to customers, and all those other things will follow. How do you manage conflicting priorities within the organization? RR: All of the conversations that I have with different stakeholders — with executives, sales, marketing, customer success, and engineering — are focused on a particular problem that we want to solve or an opportunity that we’ve identified to deliver value to our customers. We frame discussions in the context of how does this align with our goals as a business? And the product management group has the benefit of very strong insight into our company goals. Tweet This: “Frame discussions in the context of business goals.” #ProductLessons To use generic terms, goals for a company could be to increase the adoption of certain features, to increase revenue, or to become more profitable, etc. Whatever those goals are, they’re very clearly communicated to the product team and expressed throughout the organization. Let’s use a hypothetical goal — to increase adoption of a particular product line, for example. That message will have been communicated to department leaders by the VP of Product and by the Directors of Product. We get direction from the top down — from our board of directors, to the C suite of the company, to the VP level, and then down to the product line owners. There’s a lot of vertical alignment on what we’re trying to accomplish as a business. So when we’re framing a conversation around trying to increase the adoption of “x” product line, there’s very little debate around why are we trying to increase the adoption of “x” product line in the first place. Company alignment is being worked on all the time — both vertically, up and down the corporate ladder, and horizontally, across all parts of the organization; product development, engineering, customer success, sales, marketing and operations. So for us, managing conflicting priorities is well solved by ensuring that there’s consistent alignment on goals. What are some of the tools you use regularly as a product manager? RR: I have a couple different classifications of tools. I have tools that I use personally for my job, and tools that I use in a group setting. Evernote is a great example of a tool that I can’t live without. I have years and years and years of notes in Evernote. I’m also a very heavy user of Google Apps — Google Drive, Gmail, and Google Calendar. I use Google Docs, Google Sheets, and Google Presentations. Specifically, I find the collaboration aspect of Google Docs indispensable. Also, I almost always have a pen and some Post-it notes in my pocket. My wife makes fun of me because I will usually slip a little pad of Post-its and a pen into my shirt pocket before I leave in the morning. She’ll call me a dork or a nerd and ask me if she should buy me a pocket protector. I’ve actually had ink open up in my shirt pocket before. For team-oriented work, I’m not very dogmatic about tools. My view is what’s the best tool for the job? And we have myriad tools that are employed here at AppFolio. For example, we have some teams that do all of their planning work on a whiteboard. Someone will draw up a scrum board on a whiteboard so we can track stories to groom, work in progress, and so on. We also have teams that work with Trello and other teams that work with Pivotal Tracker for managing backlogs and tracking work in-progress. One other tool that I find particularly valuable is called Kanban Tool — we use it a lot for user story mapping sessions. It’s a good way to capture and memorialize information. Beyond that, it’s important to have consistency in tools that are used to communicate across the organization. For example, we use Google Sites to capture release literature and send it around internally — and it’s always the same form and the same destination. People in the company know where to go to find release notes. Additionally, all of our product managers use LIKE.TG to track their two-to-eight-week roadmaps, and those roadmaps are always in the same format. Anybody in the company who receives a roadmap knows what it’s going to look like — they know it’s not going to behave any differently. My personal go-to tools are Google Apps, Evernote and Post-its. When it comes to the tools that my teams use, I’m happy with whatever tool is appropriate for the job. And if it’s a tool that’s being used to communicate broadly, then I think consistency is more important than the type of tool chosen. How do you plan your product roadmap at AppFolio? RR: At AppFolio, product managers maintain roughly a two month outlook on what their teams are doing. I frankly don’t know the origin of that time horizon — maybe we originally had a two month release cadence at some point. Anyways, each product manager owns the visibility into the next two months of work for their respective teams. Now, two months out, things are still kind of vague. The closer we get, the greater our confidence in estimates and in the fidelity of the problems that are going to be solved. For historical reasons, our sprints are in two-week cycles — even though we now release code on a weekly basis. But since everybody in our company is used to “sprint” meaning two weeks, we’ve kept that definition. Product managers therefore work with blocks of two weeks at time on their roadmaps. Typically, the product managers will meet with their teams once or twice a week for very informal sprint planning. Then they’ll update the two-week horizon, the four-week horizon, the six-week time horizon, and the eight-week time horizon. Predictability and certainty of roadmap items decreases further out on the roadmap. Our roadmaps are communicated to the whole organization every two weeks, in a traditional roadmap form — with swimlanes, blocks, various colors, and so on. Now, for the longer-term view, we don’t really have roadmaps. We have six themes that are derived from our business objectives. These are things like expanding our market, increasing feature adoption, enhancing our user experience, retaining our promoters, etc. We revise our themes every six months because things change, or because we’ve made a lot of progress toward one theme and there’s no point in continuing — we shift to another one. Product Managers and User Experience Designers are paired to curate a theme backlog. They’re responsible for working cross-functionally to understand the various needs across the organization. They talk to customers on a regular basis, quantitative analysis, perform market research to identify and qualify opportunities. Then, using that data, they curate a backlog of problem statements that are then prioritized for teams to pick up. Tweet This: “Curate the backlog based on user input and quantitative analysis.” #ProductLessons Teams have three top priorities across all the various themes, and product managers influence the teams towards certain themes. So, if we feel like we need to put a lot of emphasis on increasing adoption of a particular feature, then that message will be conveyed. Download the free Backlog Refinement: How to Prioritize What Matters Book➜ hbspt.cta.load(3434168, 'ba6d6ffb-c21a-41c0-8f7e-7f79e553dae1', {}); The product manager will say, “Hey, pick one of these three opportunities. Don’t pick something from the expand our market theme. We’ve done that. We have a lot of work in flight over there, or we’ve put a lot of groundwork in place already for expanding into adjacent markets.” It’s really up to the Product Manager – User Experience Designer duo to curate and present the opportunities to the teams, and then the teams pick what they want to work on. What they pick then ends up on that two-month roadmap. Have a product management story to share? Contact us at [email protected].

This is the second part of our conversation with Ronnie Regev, Sr. Product Manager at AppFolio (check out the first part of our interview with Ronnie). Ronnie is the first of several product managers we’ll be interviewing about their careers. Read on for Ronnie’s advice on listening to customers, asking the right questions, challenging your assumptions, and more. How do you incorporate customer feedback into your roadmap? Ronnie Regev (RR): Customer feedback has a direct role to play in the two month roadmap or and long term product themes (see previous post). When we release an MVP (minimum viable product) — or when we release something that’s likely to test our assumptions or challenge our next big hypothesis — we’re actively looking for customer feedback. At that stage, feedback has the power to directly influence our roadmap planning. Sometimes we’ll intentionally release something that is missing a particular function we assume might be needed — for example, the ability to notify users when a certain task is completed. We can just assume that customers need notifications, or we can wait and explicitly seek to hear whether or not notifications are really necessary. And if they are necessary, what form should they take? Through which medium? Is there a better way of conveying the information the user needs? Customers may start telling us that the new feature is great, but they have no idea when their staff has completed a workflow. They may say, “If I don’t know when my staff completes their workflow, how do I know when I need to go do these other things that I’m responsible for?” If we hear feedback like that consistently — to the point where it affects someone’s ability to adopt the new feature or their willingness to use it — it may indicate a need for us to build notifications after all. Then we’ll say, “Great, this is the next thing that we’re going to work on, and it may even leapfrog other priorities on our roadmap.” Customer feedback is also a big factor in both determining, and curating the theme backlogs. There are many channels that our customers can leverage to convey their needs. We use UserVoice to collect feedback, set feature delivery expectations, and encourage our customers to vote on the ideas. AppFolio has an excellent customer loyalty team that works with customers on driving feature adoption and getting ahead of churn risks. This group is an excellent source of input into the pervasive challenges experienced by our customers. We pay particular attention to things that are challenging during the implementation process. Sometimes customers churn because the implementation of a particular feature is really difficult and painful, and if that’s the case, heavier weight is given to things that will fix the problem. Lastly, the product and UX teams gather feedback from the field on a regular basis. We all travel to AppFolio hosted meet-ups quarterly in order to maximize customer face time and conduct several in-depth office visits per trip. What are some of the biggest product management mistakes you’ve witnessed? RR: I’ve witnessed many product management mistakes, many of them my own. One of the biggest mistakes I’ve made is forgetting to challenge my assumptions. How do we really know that our customers are frustrated with the way a particular feature works? How do we know that we must absolutely build this additional functionality? Questioning my assumptions, and really doing it adamantly, is a consistent challenge. Forgetting to question things is a mistake that I see new product managers make all the time. Maybe they don’t want to challenge a very senior engineer, or the CTO who is passionate about a particular feature to build. As a product manager, it’s your responsibility to validate those statements. If you don’t, the ramifications are potentially wasted time, misguided efforts or pursuing pet projects.. I’ve seen this with associate product managers who are new to the role. Sometimes they won’t question the assertions that a more senior team member makes. Another common mistake I’ve seen new product managers make is not putting enough emphasis on learning the product, understanding the market, and learning about customers before diving right in. Tweet This: “You’ll solve problems the wrong way if you don’t take time to fully understand the context.” #ProductLessons You will start solving problems the wrong way if you don’t take the time to fully understand the context — or, in the case of B2B software, the customer workflow and motivation. How and why are they doing this today? That’s what a product manager needs to understand to be effective. It’s a mistake to try to jump in prematurely, without having the background knowledge necessary to ask the right questions. Finally, I have one last really specific mistake that has to do with third party integrations: Don’t build to the spec of an API that doesn’t exist yet. You’re basically building something on the hopes that it’s going to work a particular way, but you don’t actually have any proof. That’s a mistake I’ve made, and the lesson I learned is that when you’re working with third parties, wait until the integration point is real and you can actually see programmatic responses before you start building software. Otherwise you could end up sinking a lot of time into something that takes you down the wrong path. What is the most important skill for a product manager? RR: I think the most important skill that a product manager can develop is knowing how to ask questions the right way. Again, we all have our own biases, our own opinions, and our own assumptions. But when you’re interviewing people to understand what they’re trying to accomplish, and what’s difficult for them, you need to discard those biases. That can be accomplished by learning to ask non-leading questions. I typically hear new product managers ask customers, “Would you like this? If we develop a feature that does X, Y and Z, would you like it?” And the customer will say, “Sure, I’d love it. That sounds great.” I coach our new product managers to instead ask, “How would you use this particular feature?” And then, I encourage them to sit there quietly until the customer actually answers the question. That’s actually another tip for asking questions the right way: Ask an explicit question, and let the person answer the question that you’ve asked. Don’t add on additional qualifiers or tack on other questions. Ask the question in an open-ended format and wait. You want to understand how the customer will use something and why it’s important to them. You need to give them enough time to actually think through the answers to those questions. I learned how to properly ask questions by listening to recordings of other product managers conducting interviews, reviewing my own interviews and seeking advice from our User Experience researchers. The ability to ask well-structured questions helps product managers develop empathy, which is another really important skill to have. Empathizing with customers — understanding what they’re struggling with and what’s valuable to them — informs your prioritization and development decisions. How do you stay up-to-date on product management? RR: I definitely prioritize staying up-to-date on product management. It’s very important for my career development to continue learning the theoretical stuff, so I read about the experiences of other people in my field. I prioritize reading blog posts and listening to podcasts. I try to listen to product-related podcasts that are 30 to 45 minutes long, because that’s about my tolerance for jogging. I’m subscribed to a number of different mailing lists, which provide a curated list of articles that I value. I also follow key people on Twitter and read the things that they’re recommending. At AppFolio, I often have the benefit of being sent to different product development conferences. I usually go as a litmus test for whether or not we should send additional people — engineers, UX designers, researchers, etc. We have a strong philosophy of experimentation at AppFolio. I learn a lot from my colleagues who apply different approaches. I remember meeting a friend about six months after I started here and he said, “You seem like you’re doing great. How did that happen? How have you learned what you’ve learned?” I said that I’ve learned nearly everything through my colleagues. The saying that “a rising tide lifts all boats” is the way I see the product management team at AppFolio — there are a lot of informed, smart people and we learn from each other. It’s not just product managers that I’m learning from either, learning from other peers is a critical part of how I keep up-to-date. The two colleagues who push me most, in a constructive way, are a lead QA engineer and Director of Engineering. As for the piece of advice I’d give to new product managers, it’s hard for me to single out just one thing. But if I had to choose, I’d say learning about your market, your customers, and your product is important. Learn those things, because it’s crucial to be a subject matter expert. You’re the voice of the business and the voice of the customer. Tweet This: “You can’t do your job effectively if you don’t prioritize learning about your product and market.” #ProductLessons You can’t really do your job effectively if you don’t prioritize learning. A newly hired product manager at AppFolio recently asked “I’m getting pulled in a lot of directions — what should I do? I’m shadowing a product manager. I’m getting involved in team activities. There are all these meetings.” My advice was, “Your job right now is to understand our market, understand our customers, and learn all about our product. Build that base, and you can do the other things afterwards. But build that base first.” What is the craziest feature suggestion you’ve received? RR: A crazy suggestion that I love getting from our customers is, “Why don’t you just do exactly what your competitor is doing? Just do what they’re doing, and you’ll get it!” It’s an interesting recommendation, and I usually reply by asking, “How long ago did you switch from our competitor to us? And why did you switch?” There will be some good reason: “You guys do this and this really well.” And I’ll say, “Okay, well, why do you think we should copy them?” Finally, the customer will say, “Well, on second thought, maybe you shouldn’t copy them. There’s a reason why we switched to you guys. Keep on doing what you’re doing.” But that’s the suggestion I love the most. If we just follow what everybody else does, we’re not going to deliver differentiated value to our market. We’ll just be a copycat product, and that’s not sustainable. Have a product management story to share? Contact us at [email protected].

This is the second in a series of interviews that we are conducting with product managers across various industries. We’re curious to hear about how they got into product management and about their experiences on the job. We hope this series will shed light on trends and challenges in the profession, and be helpful to new and experienced product managers alike. The following conversation is with Shivan Bindal, Director of Product Management at Procore (a California-based SaaS company that builds software for the construction industry). Here’s Shivan’s story. How did you get into product management? Shivan Bindal (SB): I came into product management through consulting, which is one of the more traditional routes. There are three traditional ways to get into tech product management or software product management. One route is via the engineering department. Another route is through consulting, where you do parts of all different roles, and you can choose to narrow in on product management as a full-fledged career. The third route is through an MBA program, from which you can transition into an outbound product management role. I came in through that second option. I had a background in software engineering and I managed engineers. Then, I moved into program management as a consultant for a boutique software consulting company. I decided that what I really loved about my job was product management, day in and day out. And product management is what I’m doing now and what I absolutely love. What do you love about your job and what is the most challenging part? SB: At the heart of it, being more of a technical product manager, I love solving problems. Identifying problems is a big part of the job, as is figuring out what customers’ true pain points are. You need to empathize with folks experiencing pain, and then actually solve their problems and remove their frustration. As with any job, there are also significant challenges. I think one of the biggest challenges is the fact that, as a product manager, you own something that is intangible. Tweet This: “One of the most challenging aspects of being a product manager is owning something intangible.” #ProductLessons Product managers are often described as “CEOs of the product.” Well, a CEO is responsible for a staff. But as a product manager, you own the product — you don’t own the engineering team behind the product. You don’t own the marketing team that’s responsible for taking the product to market and maintaining its success in the market. Nor do you own the sales team that’s responsible for selling the product. Product managers are not general managers, so a big challenge can be fostering a collaborative environment. You need to get the job done, but you have to do so by exerting influence in indirect ways. You have to get stakeholders across the business — both internal and external — to not only buy into your vision, but to buy into the execution of that vision over time. I think that’s one of the hardest things any product manager has to reckon with. How do you manage conflicting priorities within your organization? SB: As I always tell people and reiterate to myself, there’s the science of product management and then there’s the art of product management. Things like dealing with individuals, fostering collaboration, and ensuring that everyone is marching to the same drumbeat really entail more art than science. I think you have to understand motivations when individual priorities conflict across the organization. You have to understand who’s driving the priority, what’s driving them and why they’re even at the table — why do you need them and why do they need you? Having a very clear answer to those questions will help you arrive at as many win-win scenarios as possible. All relationships have to be mutually beneficial — what’s a priority for you needs to also be a priority for your stakeholders. If that’s not the case, then you need to reevaluate. It’s often the case that you’re just talking to the wrong person. If you’re talking to a go-to-market specialist, they may have a harder time understanding the strategic value of what you’re working on compared to someone who has a broader view of where the company and product line is going. But, competing priorities are always something you have to battle. As a product manager, you have to walk the line and ask yourself, “Am I right or is the other person right?” And then you have to suck it up and just do what needs to be done in order to move forward. Another aspect of managing conflicting priorities is identifying what it is you’re really trying to achieve. In traditional scrum, when you’re prioritizing backlogs, you often have to deal with the question of whether to build new features or fix technical debt. You may also be weighing capabilities that were previously put to the side because of MVP-type release strategies. At what point do you go back and fix things or build what you never did? Or is it better to just focus on building the next shiny thing? I use a very simple model that some old colleagues and I came up with called ARC, or Acquisition, Retention, Consumption. The goal is to ask yourself, “What am I trying to accomplish?” Are you trying to encourage more adoption of your product? Are you trying to get people who are using your product to use it more? Are you trying to get people who are using your product to stay with your product? These questions help me not only in identifying which priorities make sense and also in communicating these prioritization decisions to stakeholders. What tools or software can you not live without? Evernote is a great tool for taking notes and staying organized, which is really important given product managers talk to lots different of people — both internally and externally — about all kinds of things. Trying to keep your head on straight can be really hard. I read Ronnie’s interview, and I agree with him that Post-it notes are also a great tool. I used to use digital Post-it notes for reminders, but I’ve since moved on to using a Trello board to organize my tasks. There’s a sense of accomplishment with the Kanban-style of task management. You can track tasks through the workflow to completion, which is really helpful. On the product management side, we use LIKE.TG for our roadmaps and to ensure we’re all in alignment on whatever we’re doing over the next three, six, and nine months. And finally, it’s very old school and traditional, but I cannot live without the suite of Microsoft Office products. I need to be able to write a document, write a spreadsheet, or write a presentation and leverage it. These days, though, I tend to use the Google Apps more than I use Microsoft products because of their collaborative nature. Cloud-based products are very helpful in not only communicating ideas and sharing them broadly within the organization but also in helping us on the execution side of things with our engineering squad. When we’re prioritizing our backlogs and creating our sprints, we can collaborate in real-time in our daily stand-up meetings. Download the free Backlog Refinement: How to Prioritize What Matters Book➜ hbspt.cta.load(3434168, 'ba6d6ffb-c21a-41c0-8f7e-7f79e553dae1', {}); Describe your organization’s roadmap planning process. How far out do you plan? SB: We employ the Spotify squad model here at Procore, which is oriented around autonomous, cross-functional units. Our engineers, QA, user experience, and product management folks are all co-located and focused on a specific problem space, whether it’s a small or broad one. The size of the problem doesn’t really matter; it’s about the impact and the solutions. Tweet This: “The size of the problem you’re solving doesn’t matter. It’s about the impact.” #ProductLessons The squads operate very autonomously. They discover problems they need to solve, then they ideate, brainstorm, and design. They operate in a safe space, where their ideas can be quickly validated with direct outreach to clients. Then they move on to prototyping and developing the solution, and ultimately integrating it into the product. So that’s how we build products here at Procore, and our product management team members fit that model into their processes and practices. We’re very agile. Our roadmap is strategic in nature, so we know the problem spaces we want to solve over the next three, six, nine, and 12 months. We plan roughly a year into the future, so at any point you can get a 12-month overview of what we are doing. Because we are agile, we can’t always predict precisely when a feature will be ready or when we will start working on something. I would say we have higher confidence in the roadmap items that are three months out compared to the ones that are 9 or more months out. How do you incorporate customer feedback into your roadmap? SB: Customer feedback is a fundamental part of what we do. We are very market-driven and user-centric. The initiatives on our roadmap should provide value either to our prospective client base or to our existing client base. In general, every item on our roadmap is something we’ve heard about from our clients. Depending on how far in the future an item is on our roadmap, we may or may not have confidence that it’s something we’re going to pursue. When we look at a roadmap item that’s six months out, we know that there’s some customer pain behind it, but we can’t quantify that pain. We can’t identify what the real problem is because we haven’t done a lot of discovery yet. With items that are three months out, on the other hand, the product manager has definitely been doing research — perhaps with other stakeholders in the company, either from sales or marketing or the customer success team. The goal of this research is to really understand customers’ pain points so that we can articulate them well to others in the company. At Procore, we align ourselves around solutions and we make sure to validate those before we begin any engineering work. We do not want to invest time into anything that does not realize value for our business. As any growing software will tell you, sometimes the problems we’re solving are oriented around success and scale. For example, we may ask: Can we continue to onboard clients at our current pace in a sustainable manner? If the answer is no, we may enhance the onboarding process to alleviate some of the manual work. In that example, we are solving problems for internal stakeholders — customer success and support individuals, rather than external customers. Internal stakeholders are our customers in this scenario. It’s not always external customers that we do our validation work with. Feedback is an important part of everything that happens within product management, and it’s certainly part of the roadmapping process. What are some big product management mistakes that you’ve witnessed? SB: All the mistakes I’ve made have helped me to become a better product manager. In the past, I’ve made the mistake of simply accepting what other stakeholders say. As a product manager, you can’t do that. You have to get outside your four walls and go back to the fundamentals of problem discovery and validation. You have to validate that what your stakeholders told you is in fact a pervasive problem and that solving it is worthwhile from an investment standpoint. That’s not to say you need to get lost in ROI calculations or total cost of ownership calculations all the time. However, you do need to ask some basic questions: Does the problem exist? Is it pervasive? Is it part of the core competence of your company or your product, such that you should invest in solving it? If you can answer those questions affirmatively — and if you can be confident that your sample size for the validation was large enough — then I think you are in a good place to embark upon solving the problem. What would you say is the most important skill for a product manager to have? SB: The scope of product management is all over the board. Some people differentiate between product owners and product managers, and between inbound product managers and outbound product managers. Other people confuse program management for product management, and still, others consider product marketing and product management to be interchangeable. So there’s a lot of confusion around the term itself. If I had to choose the most important skill for product managers, I would have to clarify whether we’re talking about internally-oriented product managers in technical roles or more strategy-oriented product managers. Tweet This: “The most important trait I look for when hiring new product managers is insatiable curiosity.” #ProductLessons The crucial question is: Can you understand the product? And can you understand what the market needs are? There are a lot of must-have skills for product managers, which is what makes our role so challenging and so dynamic. You get to explore so many different skill sets throughout the course of your career — it’s truly rewarding. The most important thing I look for when I’m hiring is: Does this person demonstrate an insatiable amount of curiosity? A curious product manager is one who will never be satisfied with just one answer. Another important skill is the ability to recognize patterns. Can the person identify patterns intuitively as well as statistically? Can they look at a set of data or parameters, or a set of answers to questions they’ve asked, and discern a compelling conclusion? And it’s important that their conclusion is not grounded in fallacy, and that it is not supported by confirmation bias or any other sort of bias that would prevent it from being objective. How do you stay up-to-date on product management? SB: The most beneficial information I’ve learned has come from reading. I think reading relevant blogs and books is really important, as is routinely putting your own thoughts out there for feedback. I think Scrum and agile principles should be applied at the individual level. One of the big things I always advise product managers to do is to hold retrospectives for themselves. Find 15 minutes per day, perhaps on your drive home, to really think critically about the day’s events. Did that client call go well? What could you have done to make it better? Could you have asked the questions in a different way? If there was a source of frustration, what can you do next time to alleviate it? Tweet This: “Apply agile principles at the individual level and hold retrospectives for yourself.” #ProductLessons And it’s also important to apply the information that you collect along the way. Reading has really helped me expand my skill set, and it has expanded the set of things I consider when I’m thinking about how I can improve myself during those retrospectives. Another really great tactic, which I can’t speak to much personally, is to find a compelling mentor who is successful in the field you want to be in. Be inquisitive and leverage the curiosity that you inherently have — really challenge other people to help you. All product managers should be constantly oriented around improving themselves. Have a product management story to share? Contact us at [email protected].

What a year. There are so many changes happening in product management as I write this, and the evolution only seems to be accelerating. Our LIKE.TG community of writers and speakers (and you) have led the charge behind these trends. With your support, we dove into the most result-driven strategies, popular frameworks, and groundbreaking leaders who changed the product management landscape. And in 2020 we will more than double what we’ve done to keep up with all the changes. As the year comes to a close, I’d like to reflect on some product management trends I’ve observed and reveal a few exciting things we’ll be writing about next year in the product management space. I’m excited to watch it all unfold. Well-Defined Success Metrics are Key to Product Success In 2019, most product managers are using metrics to make decisions. Sure, product managers need numbers to report up the chain to track progress around goals. And now product managers are communicating the strategy using data-driven roadmaps. Companies define the metrics that matter. Then they use them to determine whether or not a feature makes the cut. In our upcoming 2020 Product Management report, 34% of product managers said that their primary product success metric was business-oriented metrics. The availability of data and machine learning is partially driving this movement. But what’s driving this approach is realizing that gut instincts alone don’t get you winning products. We bring too many biases to the table. We make snap decisions based on our personal feelings and experiences instead of letting the data inform our choices. Data allows us to calculate product and business metrics continually. Hypotheses can now be proven or disproven in days versus months. There’s no excuse to rely on a hunch when you’ve got metrics for everything under the sun. This abundance of data also allows organizations to adopt OKRs to enlighten stakeholders. Each product enhancement and initiative has measurable, predefined objectives, and the key results can be tracked accordingly. hbspt.cta.load(3434168, '5894a003-79ce-4ea3-9804-dae280a96106', {}); Employing Blended Frameworks Intuition-based judgment calls are still part of the planning process, but priorities are more often being informed with prioritization models. Ideas and projects can be scored and stacked against each other, merging quantitative and qualitative thinking. We see increased usage of frameworks like MoSCoW, DACI, and RICE, but product teams also realize that one framework must not rule them all. In our upcoming 2020 Product Management Report, we found that they’re relying on a handful of options depending on the scale and scope of the exercise and which stakeholders are included. There are so many choices, and product managers can experiment until they find frameworks that resonate within their organization. Returning the Power Back to the Customer Worrying about customers is nothing new for product managers. Meeting their needs, anticipating their desires, and increasing customer value is what the job is all about. But customer-centricity is being embraced now more than ever. Customers are no longer “trapped” with vendors they don’t want to stick with because moving data between systems is easier. So companies are working harder than ever to build customer loyalty. There are also more choices than ever. Cloud computing and technological advances make it cheaper and faster to bring a viable product to the market. Companies simply need to be more competitive and offer more value over time. This means established firms must double-down on creating and maintaining a superior customer experience. They’re realizing that customer experience goes beyond the product and customer support. Every interaction along the customer journey influences how a customer feels about the product and the company. So organizations are making customer-centricity a core value. This is all culminating in organization-wide customer-centricity. It’s no longer relegating it to specific departments. It permeates every decision, making the entire company more sensitive to the impacts and benefits of their actions. They now strive for customer delight, not just satisfaction. To ensure they put the customers first, companies are also investing more time and resources into gathering customer insights. They’re valuing the actual voice of the customer (not just what internal stakeholders “think” the customer wants). The Growth and Specialization of Product Roles Product management was once the domain of generalists. You needed to be good at everything, given their broad portfolio of responsibilities. But as the profession matures and establishes its importance, more discrete roles are emerging. The primary factor is that companies now have product management teams versus only product managers assigned to specific products. C-level roles for product managers are more common than they were five years ago. With larger groups, some product leaders are creating more specialized roles. Technical product managers are common within larger organizations as one of the original subcategories of product management. But the rise of product ops has created a new class of product managers dedicated to this area of the business. There’s still plenty of debate regarding just how technical a product manager must be. And while product marketing managers have been around for ages (often confusing people thanks to their title), there are now even product managers assigned explicitly to growth. We’re Roadmapping Differently With agile, the prioritization and roadmapping process may have changed, but the roadmap is still necessary in an agile world. For product managers, this is more frequently meaning they shift away from date-driven roadmaps, especially those roadmaps that project a “known” future state several months out. These roadmaps are instantly out of date the moment they’re distributed. We’re now seeing more roadmaps that are feature-less. Instead of spelling out exactly which functionality comes out when product managers are communicating their product visions and priorities. They’re relying on themes that aggregate features into a higher level, and we’re also seeing more product organizations using north star metrics to guide the way. hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"}); Meeting the Needs of a New Landscape At LIKE.TG, we’re in a great place to observe the evolution of product management. We track the trends shaping our profession. We know the problems and challenges facing product managers are changing. Product managers embrace lifetime learning, so we’re producing valuable, informative content that isn’t just repackaged sales pitches. In 2019, we launched our Product Management Glossary, where we defined nearly 200 essential product frameworks, roles, and terms. We also created nine books and guides. In case you missed them, we were proud to release: 2019 Product Planning Report Career Guide for Product Managers The Product Manager’s Complete Guide to Prioritization How Agile Product Managers can Build Better Products The Customer Interview Toolbox From Product Manager to Product Leader The Essential Feature Kickoff Checklist The Power of Pricing Experiments The Anatomy of a Product Launch We also launched our email courses: Prioritization Roadmapping Metrics & Data Building a Product Team Putting Our Money Where Our Mouth is As product people ourselves, we must walk the talk. All these things that we talk about in our content (best practices, company building, experimentation, building products that customers truly love, simplicity first) and promote as concepts in the product management community, we are actively working to incorporate ourselves. We want to make the first-time user experience rewarding. We’re improving onboarding, so new customers get value from our products quickly. We’re also formalizing and improving this process, to ensure that every LIKE.TG user is positioned for success. And as we build out our team and add more specialized roles to the organization, we’re importing even more expertise in building roadmaps. These folks are flush with best practices for communicating vision, setting goals, and aligning stakeholders… all the things we know you’re doing daily. Setting a Course for 2020 Our roadmap for the coming year is focused on continuing to deliver great content and education while expanding the capabilities of our roadmapping software, so it’s even more valuable to you. You’ll see even more activity around prioritization frameworks, growth product management, and customer-centricity. We know these are areas of great importance to our community. We hope you’ll continue that journey with us as you create your own roadmaps for 2020 and beyond. And if you have any feedback you’d like to share, we’re always listening. So on behalf of the entire LIKE.TG team, thank you again for a fantastic 2019. We can’t wait to see where you help take us in 2020. Want to get ahead of the curve for 2020? hbspt.cta.load(3434168, 'e29c8e8c-234d-44fc-985b-67a542504810', {});

One of the central roles of a product manager is to drive shared understanding. With shared understanding, a team is more effective, resilient, and creative. Alignment without shared understanding is temporary and short-lived. The best teams find a way to break down complexity and speak the same language. They row relentlessly in the right direction, even when that point on the horizon shifts. In my chalk talk, I share a framework for building shared understanding with your team and other stakeholders. You can either watch my chalk talk or read the transcript below. Enjoy! The Problem: Context is Always Changing We all know that one of the big challenges of product management is sharing context. You don’t only have to share it with your team, or across your team, but you also have to share it across the entire organization. You’re basically sharing context all the time. And the challenge is that the context is always changing. The context of yesterday is not the context of today. Tweet This: “A big challenge in product management is sharing context. Because context is always changing.” In my chalk talk, I’m going to frame that problem, and give you some strategies to make sure that the context you share is the most current context, and is deep enough for your teams to be able to take action. Direction vs. Destination Think about some of the words that we use, and think about how we communicate strategy as product managers. Let’s say you’ve got a horizon, and you’re in a boat. Now for a lot of knowledge work, you’re just generally sailing west, like Columbus. You’re sailing to a point on the horizon. You’re going somewhere. That’s a direction. Now think about how people frequently state goals. They state a series of unique points along a line, that you need to be able to hit in order to get to a specific endpoint. And that’s what we call a destination. Think about those two words: One is direction, and that’s a lot more applicable to knowledge work, and the other is a very linear, deterministic goal that you’re trying to hit. Direction versus destination. Let’s take a real-life situation: You have a friend and they say, “I want to lose five pounds.” You have another friend that says, “I want to eat healthy.” Those are two different perspectives. One is a destination-based perspective (“I want to lose five pounds”). And the other one is a more systems-based perspective (“I want to eat healthy”). Now, we all know there are many unhealthy ways that you could lose five pounds. The idea is by eating healthy, one of the things we might notice is losing weight. But we might also live longer, we might be happier, and we might be less stressed. So that’s more of a systems approach. Now, the third example is this idea of cascading goals. Dividing one goal into a sub-goal, into many sub-sub-goals, into many sub-sub-sub-goals, into sub-sub-sub-sub-sub-goals. We see this in practices like OKRs, or management by objectives. The idea is that everything cascades up and connects with a higher level goal. Teams are told to focus on their individual goal. Now, that might be good in some situations. But in a lot of the environments that we’re working in, the teams that are on the front lines actually need to be able to see the big picture. They need to do this so that they can take course corrections as they’re moving along. Think about a person who’s working right there [points at lower level goal]. If they know that’s the goal and they see the context changing, what if they could circumvent all these steps and just achieve that goal in another way? What if the context changes for this goal, or if they could take a shortcut? I tried to lay these out here as we’re understanding the problem. You have destinations versus directions. You have goals versus systems. And then you have the need for teams to be able to see the big picture in knowledge work to make sure that they can take the course corrections necessary to move in the right direction. The Reality: Context is a Moving Target But the reality in product management is, we’ll do a kickoff, and at that point, shared understanding is at an all-time high. Or we think it’s at a high. But over time, we’re always fighting the downward pressure on shared understanding. The context is changing. And at the same time, we’re learning, and we’re improving our shared understanding. We might be iterating and getting more shared understanding. It’s always this push and pull on what we’re learning and the degree to which our learning is depreciating that really dictates the situation. That’s one problem. We’re always losing shared understanding and gaining shared understanding. And even when we have a new, better, shared understanding, we still have trouble communicating that. A second reality is that different people on your team have different needs. You might have someone who is more junior, who’s new at this, who may just not care all that much about the big picture, and they’re looking down here [draws line downward]. They’re looking for things right in front of them: “Can you tell me what needs to be done next, please, so that I can do my job?” Meanwhile, you have the people who are asking why all the time and the people who need to understand the big picture. And these sometimes are your most valuable employees. They want to understand the big picture, how things are fitting together, and how things relate to each other. You’ve got both of these personalities on your teams. hbspt.cta.load(3434168, '57ff7e42-ccfa-4d9e-b5be-8a0f6ba69363', {}); And the third part of the reality is, the problem-solution dichotomy that everyone talks about, where we’ll specify the problem and you specify the solution, is a lot more intricate than that. Because every problem has a solution to some higher-level problem. Even something like hitting quarterly goals, or a new round of funding, that’s a solution towards maybe reaching a higher-level goal for your company. When people are talking about problems and solutions, it’s a lot more complicated than that. Talk to an engineer for example, even the slightest interface change is a problem to solve. You have nested problems and solutions and people with different needs. And you have the fact that shared understanding is always in a dynamic state, and you’re always having to communicate it. The Solution: Mapping Context I’ve found the following technique to be an extremely helpful tool to help you get your own head straight about things, and for communicating context to your team. I also recommend doing this exercise with your team. It’s a great way to develop a shared vocabulary. And this is an issue with roadmaps as well; it’s really about having a conversation. It’s really about sharing the same vocabulary and having the conversation that yields the best results. Let me show you this method for mind mapping. 1. A Fuzzy Goal You start with some fuzzy goal. And fuzzy goals like we’re talking about aren’t the most prescriptive goals, and they’re not the big pie-in-the-sky goals. They’re something that is actionable and directional. 2. Because, We Know, And We Assume Now, everyone wants to know the why. Why are we trying this? Why are we doing this? To answer this question, we use the word because. Everyone can relate to the word because. And we throw on two other phrases: ‘we know’, and ‘we assume’. And this is absolutely essential. How many times have you gotten two months into a project, and someone says, ‘why are we doing this’? And someone said, ‘well, I guess we assumed that this was true’. And the person says, I know that’s not true. So by saying this, we know and we assume, you really make it clear why you’re doing it, and what’s the underlying rationale. 3. While And Without And the next two words are ‘while’ and ‘without’. This can be a little tricky to wrap your head around. In your quest to achieve this fuzzy goal, what are the boundaries? What resources are you playing with? A great example that I can think about is that you’re doing something that might potentially damage the user experience. You might want to create a boundary there. You know what? No matter what we do in our effort to try to improve this fuzzy goal, we don’t want to mess up the user experience. So we use these words, ‘while’ and ‘without’. And I’ll give you an example of all of this together in a bit. 4. By Trying And then finally, we have what people commonly call solutions, but I just call it ‘by trying’. We’re going to try something to attempt to move this fuzzy goal. But the most important point here is that you can nest these. And by nesting, you can start having another ‘because’ for this, and another ‘while’ or ‘without’, and another ‘by trying’. 5. Example Let me give you an example that everyone can relate to, something like eating healthy. Because we know that eating healthy might help you live longer. Maybe that’s an assumption, but I think commonly, people know that. And we assume that our relationship might be better if we eat healthy and we’re less stressed out. Because we assume that eating healthy reduces stress. We’ll do this without breaking the bank. We’ll try to eat healthy, but you know, we’ve got a budget. And we’ll do this while making sure that, we have fun sometimes. We’re going to go out and eat with our friends. And we’re going to do this by trying what? We’re going to do this by trying to cook in six nights a week. Because we think that by cooking in six nights a week, just by the nature of cooking in, we’re going to eat healthier. We’re going to do that without annoying our kids, because they watch TV at a certain time. And then we’re going to do that by trying to have a set menu ahead of time that we shop for at Whole Foods, for example. What you see here is that if you can start to state your goals this way, instead of just having a big cascade of goals that just say things like ‘meet this revenue goal’, ‘or ‘this is this metric’, or this is this other aspect of your goal’ you’re explaining your rationale. What I would like to encourage you to do is to try this mind mapping method as a way to just get your heads straight before jumping into a roadmap or another strategic document. In Summary: Resist Prescriptive Goals First we talked about the difference between a destination and a direction, or systems and goals. And next we talked about the challenges of shared understanding. That we’re always trying to grow shared understanding, but it’s always degrading, too. There’s always that dynamic happening. And then, I talked about a mind mapping method to help you develop a common vocabulary. And that conversation is critical because if you have that conversation, you can constantly get context. Tweet This: “It’s tempting to create prescriptive goals, but when the context changes, people won’t be able to course correct.” When you think about it from a product manager’s point of view, it is always tempting to have prescriptive goals. That is a temptation that always exists. And If you take a step back, that is too fragile for most knowledge work. If you just create those destinations that people must hit, then the context changes, they’re not going to be able to change course. You’re going to lose that shared understanding very quickly. What I’d like you to do is to think about direction instead of destination as you’re putting together your roadmaps. Make sure that you’re communicating the why, the data that you have behind that, the boundaries that you’ve created around your particular goal, and also encourage people to try new things. Maybe one thing won’t work, but if they can understand what your rationale is in your thought process, then they might creatively come up with other solutions that might achieve that goal even faster.

After working in the product management space for a few years, I realized that I needed to take some classic product management advice and apply it to my own life—nothing good happens in a vacuum. I’d been spending far too much time living strictly within the small bubble that was my comfort zone and not enough time exploring new things, things that truly challenged me and broadened my ways of thinking. Being a creature of habit, I knew I’d have to take drastic measures to break out of the bubble in which I lived. So, I told my landlord I was moving out of my rent-controlled apartment in Oakland, sold most of my possessions, and made my way to Quintana Roo, Mexico where I trained to become a cave diver. While it was the scariest thing I could think of doing at the time, to this day it is the best gift I have ever given myself. I had to laugh when a former co-worker from California recently referred to me as the “navy seal version” of my old self upon hearing about some of my adventures under the Mexican jungle. Contrary to popular belief, cave diving is not a sport for adrenaline junkies or daredevils. Rather it’s a sport for people who like to think, explore, and solve problems. As I was pondering this one day while gliding weightlessly through the underground, it dawned on me that product management and cave diving actually have a lot in common. If you can think like a product manager, you can learn to think like a cave diver (and vice-versa). Many lessons I’ve learned while cave diving can be applied directly to product management. Today I’d like to share a few of those lessons. 1. Never lose sight of objectives Poor prioritization and lack of focus can and will kill you, which is why we must define and live by key objectives. In cave diving, that’s easy. Regardless of where you’re diving and who you’re with, the main objective for any dive remains the same: Get out of the cave alive. Product managers’ key objectives can vary far and wide based on industry, company stage, and business strategy, but the guiding objectives are simple. Build a product that generates profits, stands the test of time, and solves a problem worth solving. All decisions we make in cave diving are made with our key objective in mind. We must constantly ask ourselves whether our actions, whether large or small, align with and support our objectives. Only when you can meet your core objective with 100% confidence should you accept the addition of potentially distracting secondary objectives such as underwater photography, survey, and exploration efforts. Safely prioritizing around objectives means maintaining an acute awareness of the impact of every decision we make. In both product management and cave diving, meeting key objectives requires us to exhibit some serious focus and restraint in the face of temptation. For PMs, that temptation may come in the form of a “shiny object” feature idea that emerges during a roadmap planning meeting — of course you can build it, but is it the right thing to do right now? For cave divers it may come in the form of a mysterious unexplored passage you discover when nearing your turnaround pressure. Sure you can explore it, but given your objective and remaining gas supply, should you explore now or come back later with a new set of tanks? While something may be tempting in the moment, you must think critically about whether the timing is right, given all other factors. If it jeopardizes your key objective, simply don’t do it. Tweet This: “In both product management and cave diving, meeting key objectives requires us to exhibit some serious focus and restraint in the face of temptation.” 2. Stay cool and level-headed under stress One of the marks of both properly trained cave divers and experienced product managers is being exceptionally good at making decisions under pressure. In cave diving, every decision is made quite literally under pressure. For every 10 meters/30 feet of depth, the atmospheric pressure underwater doubles from that experienced at the surface. In the less literal sense, cave divers are keenly aware that a single bad decision while navigating, or a momentary lapse in judgement can have fatal consequences. We absolutely cannot allow stress and task-loading to blur our judgement. Product managers are put under a great deal of pressure as well. At times it can seem like everyone around wants something from you. And surprise! They all want something different. Customers want you to improve your app’s sharing functionality. Stakeholders want you to build that new gizmo a key competitor just released. Sales is hounding you to build that feature they promised a huge prospect last week. Oh and they all need it, like…yesterday. Meanwhile, your inbox is overflowing, your performance review is approaching quickly, and suddenly your head is spinning because there is simply too much going on. I’ll be first to admit, I am terrible at managing stress. However, through my cave diving training, I’ve been able to gain more effective tools for stress management. By far the most useful lesson I learned was when my instructor intentionally made several things go wrong at once and then closed the tank from which I was breathing. At first it felt like there were a million things that needed to be fixed RIGHT NOW. But as soon as I realized I could not breathe, I was forced to think critically and prioritize which fires to distinguish first. I realized in that moment that the only actual fire was the closed tank; the rest of the problems were simply minor annoyances that I could take my time solving. When pressure is high, it’s easy to forget that (unless you can’t breathe) you have every right to hit pause for a moment so you can land on the most informed, thoughtful solution. If you’re stressed out, you’re more likely to make rash or foolish decisions. Consider this next time you’re sitting in the hot seat. Stop and think before you act. The extra moments, hours, or days you spend thinking, researching, and making educated decisions are far less costly than fatal errors. 3. Don’t be afraid to say no I’ve learned hundreds of new words since moving to Mexico and picking up Spanish as well as a little bit of German. But regardless of what language I’m speaking, the most useful word I’ve learned to use here is one I should have mastered ages ago: “No.” I used to be what you’d call a “yes person,” especially at work where I often would take on a heavier workload than I could manage. I was too afraid to say “no” to my bosses, or perhaps I didn’t know how to say no. Cave training has finally helped me break that habit. It helped me realize that it is my right to say no. And it taught me to be more thoughtful about where the intersection of “can” and “should” lies. All (decent) cave divers abide by something we call “the golden rule,” which states that any diver can call any dive at any time for any reason with no questions asked. Of course, product managers who say “no” will most likely need to prepare some explanations. But it’s important to remember that as the strategic leader of your product, it is not just your right but also your duty to say “no” when it is warranted. Some things are easier to say “no” to than others; these are things we simply cannot do, regardless of whether we want to or not. But beyond saying “no” to the many things we simply cannot do, we also need to learn that “can” and “should” are not one in the same.There are plenty of things we can do, but that doesn’t mean we should do them. We need to recognize this and act accordingly. 4. Be curious. But explore responsibly. Curiosity can either be a cave diver’s best friend or their worst enemy. Without it, there would probably be far fewer cave divers out there, and there would definitely be significantly less explored caves in the world. If it weren’t for curiosity, the team of cave divers who recently connected Dos Ojos and Sac Actun cave systems to create the largest underwater cave system in the world wouldn’t have spent 10 months working on their vision. The exploration aspect of cave diving and caving in general is perhaps one of the most exciting parts of the sport. Some exploration expeditions start with a hunch, while others are more spontaneous. In either case, exploration means getting your hands (literally) dirty with no guarantee that you’ll find what you’re looking for. Whether you find a dive-able cave or not, you should look at your efforts as a success because they teach you lessons that will inform your next expedition. But exploring the unknown doesn’t come without risks. Underwater caves are hostile environments; places where human life is not meant to exist. With unexplored caves, you truly don’t know what you don’t know. And you often don’t know much more than what meets the eye at the surface. While venturing into an unexplored cave will always carry a certain amount of risk in itself, cave divers who live to tell their tales of exploration are keenly aware of what is at stake. They go to great lengths to minimize their risk as much as possible. Product managers must take exploration seriously as well. There is no innovation without exploration and no exploration without some amount of risk. We can be more calculated about our risk by thoroughly researching before experimenting and designing. We also must be keenly aware of what is at stake at all times, and whether we are willing to face any associated risk. Sometimes we can’t simply dive right in to an experiment. Instead we must test things little by little until we have enough information to confirm that an experiment presents limited risk. Finally, we must remember that even if our experiments don’t lead us to a desired conclusion, all knowledge picked up along the way is valuable. 5. Use the right tools for the job (one size does not fit all) Cave diving is a sport that requires a LOT of highly specialized and personalized equipment for safe participation At 153 cm and 41 kgs, I am substantially smaller than your average cave diver. As such, I’ve learned there is truly no such thing as “one size fits all,” no matter what marketing materials claim. Finding equipment that works well for me has been a long and frustrating process of trial and error. But it has also shown me the true value of having the right tools for the job. One should not settle on solutions that are merely “good enough.” Whether you’re a product manager or a cave diver (or both!) you’ll be exposed to countless tools. Within both communities you’ll find opinionated advocates making their cases for the “best” tools. While suggestions from others can help you establish a starting point, it’s important to understand that the “perfect” tool for one person or organization may not be the perfect one for you. And that’s ok. Take your time experimenting with different options until you find something that works exactly as needed. Avoid looking for the cheapest option or the most highly recommended one. Research and test thoroughly; in the end, you’ll be grateful to have a toolkit that serves your specialized needs. Finally, once you’ve settled on your chosen tools,, invest time getting to know the ins and outs of how they work so you can ensure you’re making the most of them. At the end of the day, the tools and equipment you use don’t make you a good product manager or a good cave diver. But if chosen carefully, the tools you work with can help optimize your potential. 6. Give thorough briefings Every dive begins with communication. A proper briefing can mean the difference between a smooth, relaxing dive and a chaotic one. So I make it a point to be extremely thorough in my briefings. I never start a dive until everyone in my team is on the same page about the plan. During a dive briefing, I start by explaining where we are going, why we’re going there, the specific roles of everyone in the team, and the limits and scope of the planned dive. I then remind everyone of our primary objective and describe the sequencing of events planned for the dive. I also address any possible hazards, challenges, or concerns that may arise. After that, I make sure all questions are answered before giving the signal to descend into the underground. Even if I am diving alone, I make it a point to share every detail of my plan with someone else. Just the act of articulation helps me identify any gaps that I may have overlooked. As product managers, we cannot expect others within the organization to understand the who, what, when, where, and why of our product strategies. So we must take the time to explain and provide proper briefings. If you fail to articulate your plan to your team, how do you intend to get buy in and support from them? Finally, communication doesn’t begin and end with the briefing, it’s a continuous process. Your briefing or kick-off meeting is a fantastic time to discuss how to handle follow up communication. In dive briefings we often review the communication signals we’ll use while underwater. In product briefings, you can explain what methods you’ll be using to keep the whole team up to speed on product news and updates. 7. Always know where you are, where you’ve been, and where you’re going Product managers have product roadmaps to tell them where they’ve been and where to go next. Cave divers navigate the sea by using personalized navigational markers as “breadcrumbs” to help them find their way back. One of the first rules you learn as a cave diver is that you always must have a continuous line leading you to your exit. A cave diver without a line is like a product without a product roadmap; both are unlikely to last very long. A cave line is more than a piece of string to follow. It’s your lifeline. No matter what happens in the cave, you never stray away from your line. In the event of a silt out ( when sediment particles in the cave get stirred up into the water, reducing or even completely eliminating visibility), the line serves as a tactile, concrete guide back home. If our lights somehow manage to fail and we’re left in darkness, we can use the line to feel our way out with confidence. For product managers, your roadmap is your product’s lifeline. It is a living document depicting where you have been, where you need to go, and the objectives you need to meet. Even when distractions blur your vision, a well built roadmap helps refocus your attention on the objectives that matter. 8. Debriefings are the best learning opportunities The pursuit of perfection is growth’s greatest enemy. There is no such thing as a flawless product or feature launch, and any decently trained cave diver is unlikely to tell you they’ve had a perfect dive. While product managers have retrospectives, cave divers have debriefings. I personally believe no cave dive or product initiative is truly complete until there has been a proper debriefing. Product managers and cave divers who opt to skim through or completely skip debriefings miss out on important learning opportunities. And if we aren’t learning, how can we expect to improve? Have you found product management inspiration in other aspects of your life? Share what you’ve learned in the comments below!