Product Discovery with Internal Customers - All Things Product with Teresa & Petra

Hi folks, this is All Things Product with Petra Wille and Teresa Kortz. And we're so happy you're here. Teresa, this is me asking again. There is a trend that I'm seeing and I just wanted to hear your ideas about it. So if a company is working or if a product organization is working for internal stakeholders, so they're creating tools that colleagues of theirs will be using down the line. I see them rather doing meetings, business meetings, where they collect requirements than doing proper discovery initiatives, say something like interviewing. So it's really kind of they don't have a concept for it. This is my user and these are stakeholders. This is the investor to our project initiative. Is that something that you see as well? Yeah, let's get really specific here. Let's suppose that I'm making software for you. So I'm gonna make social media scheduling software for you. And because I know you, we both do a lot on social media. We're colleagues, basically. And we're colleagues, basically. So I'm gonna make software for you. Now, what I see most happen most often, and I know you see this too, is that like, I'm just gonna hop on a call like we are now. And ask you. The casual conversation. Petra, what do you need in your social media scheduling software? And we're going to have a meeting and you're going to give me all your requirements and I'm going to write them down and then I'm going to go build all that. And it doesn't work. That's what I see happening. Yeah, but it doesn't work. It's the same reason why we can't just take customer requests. Like, Petra, you're going to have an opinion about what I should build for you. The problem is you're a human and you didn't take the time to think through, because it's not your job, by the way, to think through. I just have these pain points that it just... Yeah, like what do I actually do and how does software support that? Right? Like you're not doing that work. That's the product team's job. And so I can't just say, Petra, what can I build for you? I need to say, Petra, show me how you schedule your social media. Walk me through your social media strategy. How do you schedule it? Do you schedule it a week in advance, a month in advance, a day in advance? Do you not schedule it at all? Let's walk through it. Show it to me. And then I'm looking at you all of it. Once the blog post is out, then I think about what would be great social media posts for that blog post. And then I schedule the next five social media posts for that blog post. At some point it will be from the archives, but that's what I'm doing right in the moment that I'm actually posting my. blog post. All right, excellent. So I could walk through all of that with you, collect all the details, how are you choosing, what to pull from the blog post, etc. And what that does is it gives me a much better idea of like, can I automate some of that? Maybe you don't know that some of it can be automated and you're not going to know to suggest that to me, right? But when I hear your story, by the way, if I conduct a story-based interview and I hear your story about what you actually did. Now I can start to look at, oh, I can get rid of this stuff altogether because I can automate it for you. Or hey, would it work if we had to do this instead? Why don't we have you try that before I build it into software and I can start running some assumption tests. And I think that it's easy to fall into the trap of me thinking, well, Petra is really smart. She's familiar with software. She knows how she schedules social media. Why can't I just ask Petra what she needs me to build? Yeah, and I totally agree. we all know how hard it is to think through how software should work yeah one thing that i usually encourage my coaches to do is really to i call it stakeholder map but it's more than a stakeholder map so i really encourage them to think about who are the people that will end up using what you're actually building and who are the people who want to stay in the loop be informed because maybe they have to plan change management initiatives for the rollout or something like that so they're interested in your progress but they will never ever be using the thing that you're currently creating but they have an interest in how to how the things are going right and then there is investors or sponsors or somebody like that so that's the people that really allowed you to invest the time and to kind of find a team and to decide what to work on and you have to have conversations with them how to spend your time wisely how to spend your budget wisely and what the company expects in return and these are three different groups that i want kind of um product teams that work on an internal product to reflect on before they actually plan the discovery initiatives should they talk to all of them yes do they need to do a story-based interview with all of them maybe that's not so helpful with your investor type of persona do you need to keep them in the loop yeah you want to update them every once in a while yes but that's usually something that i find helpful to do with teams that do internal product development Yeah, I think the reason why internal teams tend to skip all this stuff is they think it's going to be faster to just say, hey Petra, what do you need in a social media scheduling software? I'm going to get that done in like one hour. Okay, well now let's imagine there's eight Petras. That's not a one-hour meeting. The eight Petras are going to disagree and we're going to have a battle and we're going to send emails and there's going to be documents. Especially if you don't have the roles clear, right? After all of that, you're still going to get it wrong because it wasn't based on what anybody actually does. It was based on what they think they do. And we know there's a huge gap between what people actually do and what they think they do. And so it actually saves time. If I go individually interview each of those Petras, in four hours I can conduct eight 30-minute interviews. I can spend another hour or two drawing, identifying opportunities, synthesizing it, looking for where's my opportunities. and i'm going to come up with a way better solution we just plus you usually on top of that would have all the meetings with your stakeholders and the investor sponsor type of persona as well But that's not necessary, right? That's more of a show and tell thing then. After you conducted all your discovery initiatives, you can inform them on the progress or if they really want to be involved, you can run a casual workshop with them to walk them through your opportunity solution tree or story map or whatever you created. But if you have the roles clear, it is way easier to decide where to spend your time and in which way to spend your time with your colleagues. And they're all colleagues. That's the challenge. I think also like... coming out of those interviews more often than not i think we see process improvements right we see oh eight people are doing this in slightly different ways and what we didn't realize is sally over here came up with a really innovative way to skip three steps but petra doesn't know about it because sally hasn't shared it with anybody else yeah right yeah that's something that i see a lot happening as so it is rather unclear who owns the process and who does process optimization in product organizations that are responsible for internal tools because is the stakeholder the highest paid person in the room usually and the one owning the process and are they expecting the product team to innovate on behalf of the user to simplify the processes is that something that the company is currently interested in basically every company always says they're interested in process optimization but it comes with a bit of change comes with a bit of pain it comes with a bit of friction so is that actually really something that the product team should be solving right now are they allowed to optimize the processes and then suggest the users how to work in better and different ways i really like that you brought up the process optimization thing because that is in this environment really big question i have a member in my community right now who's going through this his product team was asked to deliver a feature for the US market that solved a pain point for internal colleagues. They released it. It worked fabulously well, so much so that the CEO is now saying, let's push this feature to the UK. So they pushed it to the UK and the internal colleagues in the UK don't want to use it and they don't want it in the product. They want it turned off. And it's because they have a different process. and this new feature breaks the process. So now this product team has a CEO saying release it to the UK and they have internal colleagues in the UK saying no, turn it off. And the problem is a process difference between the US and the UK and who's deciding does the UK have to change their process? The product manager doesn't have the authority to say that, right? So it's a little bit, it's such a sticky problem. that comes up with internal software that we often forget like who has who's empowered to make those decisions and so there is no magic wand that we can hand people to make this go away right but it's kind of it's more the encouragement if you see that being a thing then raise your concern be vocal about it this is actually the advice that i would actually give here is to say like okay and maybe maybe just raising the question of are we allowed to suggest process optimization because already suggesting process optimization can be a bit of a faux pas so that's maybe something that you want to ask before you work on an internal product i'd say yeah yeah i you know i'm gonna make a suggestion for anybody who's on an internal pro on a team building software for internal products i think if they're doing product discovery and they think but my situation is different because I want them to stop, full stop right there and just say, how can I take this practice and make it work for my internal customers? Because I've worked with a lot of internal teams and the changes we've had to make are so minimal. In fact, You have huge advantages. On your discovery process. On any of the discovery habits. That's what you're talking about. Not the processes in general. No, not the processes. But the product discovery habits. And I would say people that work with internal customers have a huge advantage. Their customers are colleagues. You have so much access to them. They want to help. They're available. They oftentimes just run the corner. Yeah, this is not always the case when your customers are external. So I think my key message here. It's not different. You should be interviewing. You should be assumption testing. And the beauty is it's your internal colleagues. So you have access to them literally every day. And I would look at how do you work so closely with them that you know exactly what they need to do and not what they think they do. Exactly. And I would add to it before you do so. be aware of that everybody every colleague of you has opinions about the thing that you're doing but i think it makes sense to first reflect on who is my target audience target user that i want to do all the discovery initiatives with and who are just people that have opinions are maybe paid for having opinions or in the leadership team are sponsoring the initiative want a regular update These are maybe not the people that you have to interview and include in your discovery initiatives. I really think that helps to, first of all, get your stakeholder map clear. This is where I think outcome thinking can be really helpful too. I've worked with a lot of senior leaders that want to get involved of like, no, I need all my sales reps doing it exactly this way. And they want to influence the process. Whereas I think if you can say, okay, if they all did it that way, what would you get from that? Oh, you'd have really clear reporting. Okay, if I can generate a report that looks exactly like this, but your reps don't do it that way. Are you happy? Oh, you are? Okay, good. So the outcome you want is a report that meets these needs. Let me go work with the sales reps. We can do that. Right? I like that example. I think it really helps because a lot of humans and especially busy leaders, we intuitively infer a lot of steps. So that leader says, I need a report like this. Therefore, I need my reps to enter this, this, and this on exactly these days and exactly this way. And they communicate, enter this, this, and this in this way on these days. They don't communicate, I need a report that looks like this. And what they miss is the opportunity to get a report that looks like this with less work, with more automation. And with the liberty of everybody working the way that they're actually super effective right now. Exactly. And so I think as a product team, our job can... be to help that leader slow down and pull out those inferences and be like, hold on, what do you really care about? Is it this or is it this? Yeah, amazing. That's famous last words, I'd say on that topic, Theresa. All right. I think we can wrap up. I liked it. Thanks, Petra. Cool. Thanks, Theresa.

In this episode of All Things Product, hosts Petra Wille and Teresa Torres dive into a common challenge faced by internal product teams—relying on stakeholder meetings instead of proper discovery practices. Why do so many teams collect requirements through meetings rather than observing real user behavior? How can product teams better differentiate between stakeholders, end-users, and sponsors?
Petra and Teresa break down why internal tools often fall into the requirement trap and share actionable strategies for conducting effective product discovery, even when your users are colleagues. They explore how to leverage internal access, the importance of story-based interviews, and how to optimize internal processes without stepping on toes.

Tune in to learn:
✅ Why requirement meetings aren’t enough for internal product teams
✅ How to map stakeholders and distinguish users from influencers
✅ The power of story-based interviews for uncovering real needs
✅ How to leverage internal access to users for continuous discovery
✅ Practical steps for navigating process optimization and organizational dynamics
If you’re working on internal tools or leading a product team that serves colleagues, this episode is packed with insights to help you move beyond stakeholder requirements and deliver impactful solutions.

Show Notes:
Internal product teams often fall into the trap of collecting requirements through meetings, leading to solutions that don’t fully address user needs.
The key challenge: Blurring the lines between stakeholders and end-users.
Story-based interviews are crucial for understanding real user behavior and uncovering hidden pain points.
Petra emphasizes the importance of stakeholder mapping: Identifying users, informed stakeholders, and sponsors.
Teresa explains why internal teams have a unique advantage—proximity and access to users—and how to leverage it for continuous discovery.
Process optimization is sensitive territory. Who owns the process? Who’s responsible for improving it?
Outcome thinking can help navigate stakeholder opinions, focusing on results rather than prescribed solutions.
Internal teams must rethink how they approach product discovery and avoid assuming their situation is “different” or exempt from best practices.

Resources & Links:
Follow Teresa Torres: https://ProductTalk.org
Follow Petra Wille: https://Petra-Wille.com

Mentioned in this episode: 
Story-Based Customer Interviews Uncover Much-Needed Context: https://www.producttalk.org/2024/04/story-based-customer-interviews/
Assumption Testing: Everything You Need to Know to Get Started: https://www.producttalk.org/2023/10/assumption-testing/
Stakeholder mapping, as covered in Aligned: Stakeholder Management for Product Leaders by Bruce McCarthy: https://www.amazon.com/Aligned-Stakeholder-Management-Product-Leaders/dp/1098134427
Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes: https://www.producttalk.org/2023/12/opportunity-solution-trees/
Continuous Discovery Habits Community: https://learn.producttalk.org/course/cdh-membership
Shifting from Outputs to Outcomes: Why It Matters and How to Get Started: https://www.producttalk.org/2024/07/shifting-from-outputs-to-outcomes/

Have thoughts on this episode? Leave a comment below.
#AllThingsProduct