The Heather Samarin Hypothesis: Customer-Driven Organizations Develop Products People Actually Want
Heather Samarin shares how to conduct scrappy research, improve your organization’s usage of personas, and get buy-in from business leaders.
Heather Samarin is the co-founder of Product Rebels and has over 17 years of experience in design, development, and management of customer experiences. She has held multiple product executive roles for successful companies like Intuit. With Vidya Dinamani, she co-wrote Groundwork: Get Better at Making Better Products.
In this episode of the Product Science Podcast, we cover how to conduct scrappy research, improve your organization’s usage of personas, and get buy-in from business leaders.
- Groundwork: Get Better at Making Better Products by Heather Samarin and Vidya Dinamani
- Product Rebels
- Follow Heather on Twitter
- Follow Holly on Twitter
- Follow Holly on LinkedIn
Questions We Explore in This Episode
How did Heather move from finance to product management? What drove her to go back to school, and what did she study? What was her career pathway through Intuit, and what projects did she work on? What was it like to work on such a ubiquitous product like QuickBooks? How did they break the platform into verticals and which pain points did they identify?
What was product discovery like at Intuit? How did they do their research, and what kinds of things did they look at? What was the biggest lesson Heather learned from Intuit, and how do you get intimate knowledge of your customer base?
How did Heather translate her knowledge of research processes to smaller startups with fewer resources? What is “scrappy research,” and how do you do it? What is the minimum number of research subjects you need to get actionable themes? How does discipline help you get the most out of every interaction you have?
What led Heather to co-write Groundwork, and why are research hypotheses such an important concept? Why should you think of a hypothesis as a rudder? How are hypotheses different from goals? What were the three pillars they identified that successful companies have in common? What are the three practices that enable you to establish those pillars?
What does Heather teach about personas to make them work better for organizations that are already trying to use them? What do most businesses misunderstand about personas? How do you decide when to make tradeoffs between efficiency and accuracy, or control versus delegation? How do you impact decision making and get commitment from others? Why can cherry picking data to support your decisions backfire?
Quotes From This Episode
Getting commitment is integral in a product manager’s success—bring the context and help others get to the same logic you had so it's a shared vision.
I see a lot of failure in product managers who never learn to build logic based on customer insight and can’t communicate it in a way that galvanizes the team around the decision.
Hi, and welcome to the Product Science Podcast, where we're helping startup founders and product leaders build high-growth products, teams, and companies through real conversations with people who've tried it and aren't afraid to share lessons learned from their failures along the way. I'm your host, Holly Hester-Reilly, Founder and CEO of H2R Product Science.
This week on the Product Science Podcast I'm excited to share a conversation with Heather Samarin. Heather is the Co-founder of Product Rebels, a product management leadership training company, and has over 17 years of experience in delighting customers through the design, development, and management of customer experiences within both B2B and B2C marketing and product management. She started her career and spent over 13 years at Intuit, where she built her passion for customer-driven innovation and leading successful product teams and delivering delight and growth.
Since then she has held multiple executive products roles within multiple industries like social gaming and healthcare markets, where she led product strategy and new product design and development. She holds a BS in Finance from California State University and an MBA in Marketing from Santa Clara University. Heather lives in the Pacific Northwest and enjoys mentoring local entrepreneurs, angel investing, and taking advantage of all the beauty that living in the Northwest has to offer. Welcome, Heather.
I'm excited to have you on the podcast.
As we chatted before I do always like to hear a little about people's stories so we'll talk a little bit about that and then we'll go and talk about your new book. How did you get started in tech?
Yeah, it's an interesting story which I think a lot of people in product management fall into it, it's not a traditional path. I started in finance, actually. My undergrad was in... I started in graphic design, switched to finance, don't ask me why, it's a college student and you'd never really know the reasons why you make decision to do. But I moved into finance and jumped into Intuit, what I felt like I was a kid in my early '20s. And moved into being division controller for the Small Business Division which was an honor to be in that role, but knew that my passion was really... I spent a lot of my time in investment analysis, new product innovation analysis and got excited about being on the business side and the sort of product innovation and product decision-making and really around learning about customers and sitting in customer's shoes.
And I was so blessed to have my coach who was Bill Campbell. He is known to be the coach in Silicon Valley and he was very influential in my career. I just, I couldn't have made it without him. So he coached me along, he said, "Heather, if you want to be in the business side you're going to have to go back to school because you're always going to be known as a bean counter in the company." And he was right. And so I went back to school. Intuit was gracious enough to help me and support me through that process and then moved into the business side.
This is where I jumped into QuickBooks, product and brand management and immediately was surrounded by wonderful product thinkers, designers, customer-driven folks, Scott Cook is one of them. Just blessed in the education that I had and sitting in customers' shoes and making customer-driven decisions. And so I went on to stand the product line for QuickBooks. I launched QuickBooks Enterprise Solutions which is now one of their larger businesses. All through this, hey, there's this new problem we've identified in this new segment within our QuickBooks space, let's figure this out and it was just an exciting time.
And from then on I had the passion for more newer product development. Intuit was a really big business. We had Turbo Tax QuickBooks, Pro Tax. I mean, some of the really big leaders in the market at the time. And my passion was really in new team, new product and rolling up your sleeves and observing customers and translating that into new innovation. And so moved to San Diego and led the Turbo Tax Product Management team as VP Product Management at the time, and then I'm like, "Look, let's launch something new and jumped into a new product and new business model for Turbo Tax at the time, which was really fun.
But then the ask was Heather come back to the bigger business, bring back the innovative thinking into the broader, bigger business. And I did that for a little while but I think I still love the small team, left alone to your own devices to learn and then infuse it back into the business. I left in probably 2000... Oh gosh, seven or something like that, and left there on a Friday which was bittersweet. I mean, I was so lucky to have had my career there at Intuit and learn from such wonderful product thinkers, but I wanted to take that education and bring it to startups.
And so I jumped into a startup on a Monday after leaving on a Friday and just went right into it, and helped a video chat company evolve and change their strategy and build B2B strategy and a B2C strategy which was a lot of fun, a lot of work. And then so from then on that was my thing. I played multiple product leader roles, executive roles in multiple startups and just love that, how do I understand this problem in a way that I know I can solve and who am I going to solve this for? And the whole experimentation, scrappy research, these are all things that motivate me and I've been doing ever since. And I do it in consulting on top of my job as a product rebel with my business partner Vidya Dinamani.
Awesome. I'm curious, I think all of us have heard of and probably touched at some point QuickBooks. What was the products like at the time that you worked on it?
Oh boy. I mean, it was the leader when I joined and the question was, how do we continue to grow? And so the real focus was deepening our knowledge of small businesses. We're really focused on what we called the small business, 15 and under employees because that was the break in regulatory requirements and financial management needs so we've really been focused on this 15 and under employee base.
And there were two aspects to where we wanted to experiment and learn on how to grow at the time. One was in verticals. We were really good for a cross section of small business but we hadn't delved into the different verticals because there are very specific needs for a product-based small business versus a service-based small business, that's just one differentiation, but within product and within service there's a bunch of other unique identifiers depending on which vertical you're in. And so we went down the path of QuickBooks, developer network was one way we were able to get open up QuickBooks and get developers helping us help different verticals within the marketplace.
Oh, that's interesting.
We also did some product line extensions. We launched the POS application, point of sale, so retail businesses. There was this whole path of learning about verticals and how to solve them in a scalable way. And so the other piece of this was this market of growing pain. We had a lot of businesses that had some growing pains on QuickBooks but didn't want to move because they loved QuickBooks, but there are a number of transactions and their business needs were becoming more complex.
And the 15 and under businesses usually had one person, maybe the owner, that was doing all the financial management. And as you grew you were starting to hire an IT person or a payroll person. And so we went down this path of really understanding those customers that were having growing pains. And that's where we had to learn about, well, who are we going to solve? We couldn't necessarily solve these big manufacturing firms with the way we had built the product at that time and so it was really thinking about the roadmap to get us to solving for the bigger businesses.
And that was the other path and at the time it was really exciting. We were able to expand the product line extensions successfully and then move up the market segments in terms of larger based businesses and turn the single software application renewal model into more of a service-based business for bigger businesses. And yeah, it was a really exciting time.
Yeah, that sounds incredible. What was product discovery like in the company at the time or in that unit?
Yeah. This is where I feel like I had the best part of my education. Some really great product thinkers at the time including Scott Cook, we focused on observational research. I wasn't a UX researcher, I wasn't a UX person at the time but Intuit really expected their product folks, product management to conduct observational research. We had a program called Follow Me Home which was a creepy name as you think about it now. But we actually followed businesses, we went to the business office whether it be in the home office or in their offices and sat there for the day and watched how the interactions between the employees and the company where things were relative to the computer that they were on. If you're writing checks and you had to print them out, what were the dynamics in the office and how did they operate or interact with their vendors?
And saw it, we felt it, it was really about sitting in the shoes of your customers or prospects in this case to truly understand them intimately. Which made us significantly better at making faster decisions, getting to the right answer faster, but then also just being able to make the right trade-offs in which features were we going to release first, how we were going to design it. Without that intimate knowledge of our customer base I think we would have failed and I think that's one of the biggest things I learned at Intuit that I took with me and it's invaluable.
Yeah, awesome. And one of the things that you said in this journey of yours was about doing scrappy research. And having been at such a big company and then being at startups I'm curious, how do you define that? What does scrappy research mean to you?
Yeah, great question. We go pretty deep into this in our book. There is a time and a place for big research projects so we absolutely support that. But as a product leader, whether you're a founder, whether you're a product VP or a product manager, the constant connection with users or prospects in helping you make day-to-day decisions, we make day-to-day decisions on the product. Whether or not we're going to tweak this or whether or not we're going to launch this feature or how we're going to release this feature, we're making decisions daily. And those big event-driven research projects are fantastic in certain arenas, but we have to find a way to conduct research on a regular basis.
And so scrappy research is really a few things. It's five to seven people that you're interviewing, it's a disciplined script or moderator script but a fancy word for a question list, and it's disciplined approach to who you're talking to, so the five to seven people you want to make the most out of it. Science says five to seven people will get you actionable themes. And if you've got an ongoing pipeline of customers or prospects that are within a similar profile, obviously you don't want to be meeting with just a broad set of folks because you're going to get a different answer every time and you're not going to be able to take action.
This is when there's some real discipline around setting this up, but once you have it set up and you've got a pipeline of users and prospects, you've got hypotheses that you want to test a good script, then you have a successful scrappy research practice where you're talking to five to seven customers a week, whether that be on your lunch break, your morning coffee, depending on where your clients or customers are, it enables you to make insight-driven decisions constantly. So you build confidence, your team has confidence in you and your team. The leadership team has confidence and you've got good logic behind your decisions and you're confident you can keep moving forward.
I'm such a big fan of that kind of research so I love hearing stories about that being used throughout different types of places. Did it look the same in the startups as it did in Intuit or was it a thing that you were only able to practice at one or the other?
It was a little more formal, I will say. At Intuit we had a UX team who would make sure that we had a clear pipeline of users, moderator scripts were a little bit more polished. But we were able to talk to customers all the time at Intuit and it was expected. We would sit in a meeting with at the time Steve Bennett or Bill Campbell. When we were proposing something or a big pivot in the business, it was, well, what did you learn? What was telling you that this was the right thing to do? And so we were sort of... It was expected of us so we had no other choice, I don't think. In startups, scrappy research is all you got, right?
You don't have the cash for the big event-driven research even once you're funded and you have to make decisions so quickly that scrappy research is all you got. And oftentimes I come into startups where they don't have the discipline and so when they learn they're hearing million different ideas and it's hard to prioritize and navigate through everything that they're hearing. And so really scrappy research isn't just, I'm just going to go talk to a customer today. It's nice, don't get me wrong, but it's being a little bit disciplined so that you make the most out of every interaction that you have.
Cool. You also mentioned the hypothesis and the role that that plays. Tell me more about that.
Yeah. You're teeing up the book. We go and do a lot of this concept of a hypothesis. In order to make any research successful, the idea is using a hypothesis as your rudder. It's awesome to be talking to customers on a regular basis but if you don't have a rudder and you don't have a goal for what you want to learn, then it's a struggle. You come back with ideas or thoughts that then get sort of turned into, oh, what if we did this? And a lot of what I call shiny objects, and I think all product people are familiar with that term.
And so we really advocate every study, every interaction you have with a customer or prospect you come with a goal and your goal should be something around a hypothesis you have about a product, about a pain point, about a problem, and be able to ask questions to help you validate or invalidate. You shouldn't presume that you have the answer but you're walking in with a goal and that goal is in the form of a hypothesis or a hypothesis that allows you to focus the conversation.
Can you give us an example?
Yeah. My most recent company that I was working in was a healthtech startup and it was a online... We called it electronic consult where a primary care provider would have an ability to ask a question of one of our specialists, we had 100 and some odd specialists. And the goal was for underserved populations the primary care provider could get access to a specialist faster than that person could get access to a specialist. If you're underserved you may not have insurance or you're on Medicare and it was tough to get into some specialists. It's tough, you're access time could be up to six months to be getting care.
And so what we tried to do was cut that down to hours as opposed to months. And so one of our hypothesis was specialists would require payment for their time equal to what their hourly rates would be. So cardiologists, for example, they were making 400 at the time, this was four or five years ago. They were making about 450 bucks an hour, some more, some less. And so we were thinking, "Oh my gosh, we have to really get in a myth, how we're going to compensate these specialists to make sure that this business model works. We can't go to a primary care provider that is working for an underserved population that only gets Medicare reimbursement and pay the specialists 400 bucks, it just wasn't going to work out, the model wasn't going to work out.
And so we were trying to find other ways, our hypothesis was they were going to require a compensation near their current compensation. And so we went in without a hypothesis but the way we asked questions was, "Okay, here's the concept, what do you think of it?" And we tried to be very unbiased, not presuming the answer but our questions were all around getting at whether or not what they would expect in return for working in this concept in this way with primary care providers.
And we were shocked to find that that is not what they expected. What they were excited about which was totally new to us was, "Oh my gosh, I have so many patients in my office today who could have been cared for by the primary care provider by giving them an ask for a different diet. And here they are, they're in my waiting room, and people that really need procedures that I can only do are sitting and waiting months because I have all these people in my waiting room now." And so the opportunity to..." I'm calling it educate, which is a little pejorative, but the opportunity to help primary care providers help their patients with stuff that they can help them with. "Instead of referring them to me we'll actually help everyone. You're going to help the patient of the primary care, but then also I can actually take on more patients that seriously need my help."
And so that was a big aha but we wouldn't have known that had we not made sure that we're walking in with some sort of hypothesis and then surround our questions to validate or invalidate that thinking, and it enabled us to change the way we thought about the interaction between the primary care and the specialty care provider. And it's that kind of focus, how do I just walked in and said, "What do you think? What do you think about this? Do you like it?" How would you interact with a primary care provider and just sort of winged it. I don't know if we would have gotten themes across all the specialists that we talked to to help us come to that conclusion. And so the hypothesis is really just the rudder on where you're going to focus your time with that stakeholder.
Yeah. Thank you for sharing that story, that's a great example. So you mentioned that when I asked about hypothesis that I was teeing up the book. Tell us more about the book, what is the book about?
Yeah. The book is called Groundwork: Get Better at Making Better Products. It's a book that came out of a lot of wins and failures for Vidya Dinamani and myself, we both worked in Intuit at the same time. And since then we've led teams and have again won and lost in quite a bit. And we found there some key themes that we were seeing across different companies and different product teams. And a few of them were an inability to say no, and I think we all have felt that. You get great ideas from your CEO, your sales people, your board, your friends and customers and it's really hard to say no. And so what that usually ended up with was a backlog, a mile-long, and not being able to make good trade-offs, fast trade-offs.
And what usually ended up was you were either building a really complex product feature blog, too much stuff. You had a confusing value proposition, didn't really know who you were and sort of flailed in the market. I'd had those experiences, Vidya had those experiences and all of our clients, and when we walk in have one or two of those, can't say no, the backlog is way too long, can't decide on what to do, what not to do and decisions overturning because we had a lot of opinion-based decision-making.
And so what we learned over all of this was there's a few key pieces of groundwork, and this is sort of how we get into the book. There's three pillars of groundwork that we felt like if you didn't have these, those problems would persist and you'd end up with unhappy customers. The outcome is no growth, unhappy customers. And the three pillars that we felt like if they were there, and we'd seen these in successful companies over and over again, if they were there, you had a better chance of winning.
The first was a problem statement. This is no doubt. Everyone knows yeah, yeah I understand we need a problem statement, but we've defined, we've called it the convergent problem statement. And it's defining the problem in a way that is very clear of what you're not going to do and it's very clear who you're going to do it for and, and giving a sense of focus to the team. The second is actionable persona. And everyone hates us when we walk into a room and ask for, do you have personas and what do they look like? Because personas have gotten a hugely bad rap over the last couple of decades. And they sit on the shelf, UX is the only people that use them, they're just not usable, nobody uses them. And so we've redefined how to build a persona that you to make easy trade-offs, easy strategic decisions and so we go into the science behind a good persona.
And the third is taking those two, a problem, a persona, the person you're going to solve that problem for, and then going deep in observational research and understanding what the needs are related to that problem/persona combination. And we call these individualized needs. And we go into a lot of detail but essentially it's for each problem/persona combination in isolation you're understanding their environmental context, the challenges they have in the task that you're trying to impact, and you're prioritizing by pain or by prevalence across that persona base and you're getting a very clear picture of that isolated look between problem and persona.
And you do this for every persona that you have or that you think that you should be solving for. And knowing these in isolation allows you to say, "If I focus here, here's how I will approach the design for this particular need or a particular feature that needs this need and here's the trade-offs then I will be making, I won't be solving for this person." And having those really clear individualized needs sets allows you to make better decisions, understand the implications of those decisions immediately, and be able to communicate those to your leadership team so that you can get commitment because they have context. And those are the three pillars.
There's three practices that enable you to establish those pillars. One is hypothesis which we just talked about. Have a rudder when you talk to a customer. Make sure it's helping you understand the problem better, understand the person or the persona better, understand needs better. And then a scrappy research practice, we go into that. And then the third is a biggie for product, which is, we all have to influence people that don't report to us, and we all have to get their commitment to execute on the decisions that we are making or that we're facilitating our leadership team to make around product strategy and the like. And so the third practice is being able to get commitment, what are the tips and tricks and techniques or the science behind getting commitment among folks that don't report to you and keeping that commitment, minimizing decision overturn, minimizing decision delay, because you just have too many opinions in the room?
So it's leveraging these practices that enable you to establish those pillars and then evolve them because they're going to evolve as you learn more, as you expand. And so we believe that these three, these really six elements your hypothesis and your practices, they're synergistic and self-supporting and evolutionary for the business.
Yeah. I'm curious, I think you made some statements about personas and we hear a lot from different types of companies, and some are happy with the way they're using personas and some are not, right?
What are the things that make the way that you teach personas really work?
Yeah. The first which I think everyone will agree with, minimize demographics, it's not about demographics. The second is it's more about attitudes and behaviors which again is not really new but it's in how we state the attitudes and behaviors, we always do it in the voice of the customer. And so we will quote a customer in their own vernacular and make sure that each attitude and behavior that we have in our persona are mutually exclusive in the way that they impact the way we think about product decisions and design.
The third is what we've introduced as these character traits spectrums. Everyone has thought about this whole idea of tech-savvy versus tech-phobic. If you're a software designer or software product leader you've thought about that at least once in your life. If my customer is more tech-phobic then I might approach the onboarding experience with a little bit more handholding. That's a spectrum that you place your user on that allows you to make better decisions. We've put a term to that which is called character traits spectrums and there are many, depending on your industry, depending on the medium of the product or service that you're offering.
For us like in QuickBooks and Turbo Tax there was data accuracy versus efficiency. That isn't very clear from... It's not intuitively a trade-off, but in financial management it really is. The more we wanted to ensure that a customer had confidence in the numbers we were showing them on the screen, it took a little bit more time out of completing that task. There were times where we had to make trade-offs between efficiency and accuracy.
Another one was control versus delegation. Where are your users on that control versus delegation? Again, this was really in accounting, financial management, that really helped us make decisions about how to approach design or where we were going to prioritize features and make trade-offs. There are character trait spectrums in most industries and so it's identifying what those are and making sure you're translating those into your persona so that your trade-offs become a lot more simpler and you're a lot more confident in your decision-making.
Awesome. That's really helpful and dovetails really well with a lot of the things that I teach when I work with clients as well. We also have an approach to that. What about impacting and getting commitment from others? Tell me more about how you coach your clients to do that.
Yeah. Gosh, this stuff fires me up, on getting commitment. Too often we see product folks. They might cherry-pick the data that they gathered that supports their decision. And because we are working with people in different functions, say sales, technical support, who also talk to customers maybe in a different context, if they're only hearing what you're cherry-picking they may give you the nod in the room with a product decision but as soon as you walk away they're going back to their leader saying, "I don't agree, this is what I learned." There's that distrust with cherry-picking or just lack of understanding or lack of gathering additional feedback beyond what you're seeing.
And that's what I see a lot of failure in product managers, they never learn to create context, build logic based on customer insight, and being able to communicate that in a way that galvanizes the team around the decision. We call it the shared vision, that's a low-low term corporate speak, but I really do love this term shared vision. It's not consensus, it's being able to democratize the data at hand. What do you know? What does everyone know in the room and what's the most logical decision to be made at the time?
And if everyone feels that they have the level playing field of data that everyone has in the room, and you're making a product decision even though you might have to make a leap because you have to make an assumption somewhere,t even though they may disagree with it because their gut tells them we should be doing something else. But the data shows this is what we've learned and we're going to make a leap right here, are we all holding hands and do we have shared vision to move forward? That's when you get commitment.
And again, too often I see product managers trying to either gain the data that they see or not reach out into their organizations and validate what they're hearing so that they walk into a room and they've got shared context, shared content, shared insight, so that that decision is committed to. And because product managers... That's their life, they have to get commitment from technical support, sales, you name it, once the decision is made. And that's why we have this chapter in the book or this section in the book, because getting commitment is so integral in a product manager's success or product leader's success, it's just at a different level. You have to bring the context with your CEO, your board members, and help them get to the same logic you had. So it's a shared vision as opposed to, well, I don't agree and therefore opinion-based decision-making, that's what you want to avoid.
Yeah, absolutely. If somebody is maybe mid-career and looking to grow to a more senior or leadership position, what is the advice that you give them?
Sit in the shoes of your manager or sit in the shoes of your CEO at all times. Don't think projects... This is actually one of the things I learned from Bill Campbell again. I got the feedback, "Heather, as long as you're sitting in my shoes when you are proposing decisions, doing analysis, and thinking about the implications of the decisions that you're proposing, you will win every time in your career." And I did, that was something I learned. And if I don't know what the CEO might think about a potential decision, I go and I ask, I trial-balloon. "Here's what I'm thinking about, what do you think? What are the implications? Am I missing something?"
And that even in the product manager one role, if you are not thinking in one manager above you, or as the CEO, again, I'm not saying that the product manager is the CEO, I'm not a huge advocate of that. I think product people have a very specific role in the company. But if I'm not thinking about the implications of the decisions in strategy or in features or the like on how it's going to impact the organization, impact our overall growth, how it fits into the overall business strategy, then I'm failing as a product manager, and that's the best advice I've ever gotten in my career.
Awesome, thank you for sharing that. It's been such a pleasure to talk to you. How can people find you if they want to learn more or where do they find the book?
Yeah, great. Our website productrebels.com is a great place to find the book, find how we help product teams. You can email me at email@example.com, totally open for discussion, love learning more from product managers and product leaders who are struggling with problems. Yeah, and our book is on Amazon, Groundwork: Get Better at Making Better Products.
Wonderful. Thanks so much, Heather. It's been a pleasure.
Thanks so much, Holly. I appreciate it.
The Product Science Podcast is brought to you by H2R Product Science. We teach startup founders and product leaders how to use the product science method to discover the strongest product opportunities and lay the foundations for high-growth products, teams, and businesses. Learn more at h2rproductscience.com. Enjoying this episode? Don't forget to subscribe so you don't miss next week's episode. I also encourage you to visit us at productsciencepodcast.com to sign up for more information and resources from me and our guests. If you love the show, a rating and a review would be greatly appreciated. Thank you.
The Jackie Bavaro Hypothesis: Cracking the PM Career Means Leading With The Right Questions
In this episode of the Product Science Podcast, we cover why Jackie wrote books about PM interviews and careers, how product organizations evolve as a company grows, and what great product leadership looks like.
The Adam Thomas Hypothesis: If You Do Research Well It Never Feels Like a Waste of Time
In this episode of the Product Science Podcast, we talk with Adam Thomas does to create a disciplined and clear approach to product research.