Key Points
- The importance of having an open channel for feedback that’s easy to use
- Using support and other customer inputs to feed into the decision making process
- Using an open roadmap to more easily engage with users
- Feature requests are just the first step to an ongoing dialog in understanding the motivation behind them
- Segmentation is absolutely critical to understand value and impact
- All decisions should be made based on how their value and effort map to the company’s strategy
- Having all teams look at the same roadmap helps in creating alignment
- Weekly meetings with all teams also help in understanding what each is hearing from customers and map it to the current strategy
- Being careful with big, important customers, as they can derail the rest of your strategy
Transcript
Daniel:
So Hannah, can you tell me a little bit about yourself and your background in product management?
Hannah:
Yes, of course. So, I’ve been working in kind of around product management, particularly in the software sector, for about 11 1/2 years. I came from kind of project management, which has been quite interesting to watch how that’s evolved into product management. So looking back, I’ve probably been doing product management from the very beginning but it was all like web-based projects. And then I guess up to maybe about five, six years ago, that role began to evolve into running SaaS products, so Software as a service, which is a different delivery model but has many of the same challenges that you find in project management in that sector.
Daniel:
Cool. And can you tell me a little bit about your product Receptive and what your role there is?
Hannah:
Yep. So at Receptive, I’m the co-founder and the CEO. The business was born out of having a SaaS company previously and constantly struggling with understanding feature requests from customers and internal teams. So, we started building a tool to fix that problem within our last SaaS company, and then very quickly realized it was a problem for a lot people. So, we spun it out as a separate business and we’ve been doing that full time for about a year now.
Daniel:
Awesome. Okay, so let’s go over the product development cycle. As we’re trying to find out for things to do and things to work on, we usually tend to resort to doing interviews and doing some more of a qualitative research. What are your go-to tools and kind of questions that you try to follow when you are doing customer interviews?
Hannah:
Generally, there’s a couple of things we do. We’ve got an open channel all the time to get feedback and features from customers and that has been revolutionary in terms of what we build into our product, because we’ve found that our product function works very closely with customer success. And when the customer success do outreach work, you tend to find customers or prospects that’ll give you big projects they want to see delivered in your software. And then you’ve also got support channels and you tend to find bugs and odd feature requests kind of creep through there. But having an open channel and a way for customers to just do their day-to-day use of the product, kind of suggest features and give feedback, we’ve found we get a whole swathe of feedback and features that they’d never tell us on the phone or through support. So that’s been… I’d highly recommend that to everyone. Just give your customers a channel, basically. And you pick up loads of things they’d never complain about or that aren’t big enough to be at the front of the mind. Does that make sense?
Daniel:
Yeah.
Hannah:
I could explain that more.
Daniel:
It does. It does. That’s quite interesting. You think that the fact that there’s open box for getting suggestions means that people will be more willing to contribute to their own ideas and things that they might want, right?
Hannah:
Exactly and it’s a transparency thing as well. We expose our road map publicly and I appreciate not everyone… Is it not appropriate step for everybody. We only expose certain things, but that mixture of an open channel to give feedback on a day-to-day basis. And that kind of that view of progress they’ve got and where the product’s heading. Really does engage the users, like the customer base really well. They love it, don’t they? And they feel like they’re having a real input into the process, which of course they are, but it’s nice to open it up to them in that way, I think. Really helps.
Daniel:
Great, but that begs the question for me which is… So people will probably project their own ideas of how the product should be or their own experience of other products that they are seeing. And the kind of feature request that they might put out to you, might be probably biased or not even be aware of all the capabilities that you might be able to do. It’s very solution-focused and it might hide the true problem behind what they’re trying to ask. So how do you make this a a two-way conversation in order to try to really understand the problem that they’re facing?
Hannah:
No, I completely agree and I think it’s an interesting thing we see time to time. What we were talking about last week actually is, I honestly believe that customers, their currency, their conversation with you, is always the feature request. They don’t say, “This is my use case, this is my problem.” They always say, “I need this button to be red,” or, “I need your product to do X.” So we get around that, again, through this open channel we’ve got. We have an ongoing dialogue and discussion where our focus is always not what do you want built, it’s why do you want it? Our company is focused on understanding that question the whole time. You’ve gotta ask why not just understand what someone wants but why they want it. So we have that open discussion, and also we expose that to our other customers and prospects as well. So if there is a feature request that’s being made or a particular piece of feedback. If 20 people jumped on it and say, “Oh yeah I need this too, I need this, I need this.” Then it adds more weight to the argument that there is a real problem and with all those different voices and that discussion going, you can very quickly get to the bottom of it. But I completely agree, I think your product management is… There is that danger, isn’t there? To just go, “Oh they need this feature, let’s build it.” But you’ve always gotta ask why. That’s what you gotta do.
Daniel:
Okay. So what you do is that you ask the why when a feature comes in. Then that gets exposed to the entire user base?
Hannah:
Yep.
Daniel:
And on that people may be able to comment and add a few notes. And then you try to dig into their own needs through that channel, right?
Hannah:
Exactly, yeah. And it kinda goes beyond the customer for us as well, we involve… We often find prospects, or sales team will come and say, “Oh actually, I’ve got 10 prospects who are asking about that as well.” So you can very quickly see if there’s an actual gap in your product versus, like a request that’s come in but it’s… It’s a strange one sometimes, you’re marketing, you’ve not positioned something correctly, sometimes you’ve not explained something well, we saw with our last product in particular which was more complex. We sort of make a feature request and the feature was there, it’s just it was poor UI. So yeah, again, it’s just always think about why and you can get to that stuff very quickly, I think.
Daniel:
Okay. That then leads to trying to find out, “Okay, so I’ve got this whole set of features or needs that customers are facing,” and how can you understand what’s truly valuable? I mean, how can you know the impact that something will be having and how can you try to validate if this applies to a broader customer-base or just to a few vocal voices?
Hannah:
Yep. That’s a good question and it was a massive pain point previously. So what we do now is there’s two things we’ve introduced to get around that; one is prioritization and the second is segmentation. So from a priority point of view, all our customers and our internal teams prioritize the feature request just with little sliders, and when we introduce that step, you could put our old roadmap next to our new one and they were completely different. It was just like… It blew my mind, I was like, “Wow, that’s really cool!” So understanding priorities is an absolute must. You’ve got to understand what’s important to people. And I think having a method to capture that ongoing is important as well, because we’ve seen with the cohort analysis we do, you can get someone at the start of the use of your product, and different things are important to them at different times, so having a mechanism for them to change the priorities over the lifecycle of your product is really important.
Hannah:
And then secondly, in terms of value, you have to understand where that feedback’s coming from. You’ve got to know what’s important to your different customer segments or your teams internally, so I think this question a bit further on but I’ll touch briefly on it now, in that we understand what our big paying customers need, the small ones, trialers, churners. What the Sales teas need, what customer success need, and bringing that all together helps us make proper decisions in kind of a framework and the strategy for the business as a whole. So I think you’ve got to build something your customers love but you’ve got to build the product that your business needs as well, and having that data and that understanding allows you to make better decisions around where you put your resources in terms of development I think.
Daniel:
Right. So let’s dig into the user segmentation thing. You talk a lot about a lot of different segments that people might be looked upon and maybe either through their lifecycle on the product, maybe the value they get from the product, and maybe some other variables also. Can you walk me through your methodology, your line of thinking on that regard?
Hannah:
I think it’s something that, that kind of set will be different for every business, but for us being a SaaS product we care very much about what our paying customers need versus free-trialers. We’ve got like a two-week free trial, and we get a lot of useful feedback on feature request in that data set, but separating it out just stops the data getting skewed, like too far one way or the other.
We also look quite closely at job role as well, that’s an important one for us, because our product is used by lots of different teams within an organization; we like to understand what the C-level need, what product managers need, what customer success need and so on, because when you’ve got a product that spans an organization, every user in that group has a kind of different view, don’t they? And a different interest on different parts of your system, so we’re interested in that. And also, industry as well, we find some interesting differences between what people need based on the industry they’re in. So that data set, that segmentation changes as well for us. It does change, we do evolve it and we bring different things in. We also segment the feedback on feature requests themselves into categories. So we’ll have like a lump of UI, kind of like a lump of backend stuff and all this kind of thing, and that really helps so we can look at, “Okay, from a UI point of view, what’s important to product managers for our big paying customers?” So we do segment quite granularly in a lot of cases, I think.
Daniel:
Right. But then I guess you have a lot of different buckets of what’s important to different groups of people or different areas of the product, a lot of different things. How do you bring this all together in a way that you can say, “Okay, so my roadmap will be built out of what’s important to all of these different parts”?
Hannah:
There’s two key things there; one is, we’re bringing customer value into that equation as well. We know how much a customer is worth and what they could be worth in the future, so that’s one kind of value-metric we bring in. And the second one is the overall strategy, so we’ll sit down and every month or every couple of months we’ll outline, “What’s important to the business right now? Is it expansion revenue? Is it growth for new customers? Is it we need to do a UI project, because that’s where we’re getting a lot of feedback from?” So the whole thing is based in the framework of the strategy of the company, what’s important to the company now?
Actually there’s a third one. The third one we bring in as well is development effort. So, we very quickly, we’ll have this visualization of the features that are gonna add the most value. That are kind of low development effort, versus those which are gonna be a lot of effort to develop. But they’re gonna be really low value, so we’ve got an actual kind of visualization of those things, bringing in those metrics and that helps us kind of map out and plan what’s gonna be best.
Daniel:
Right. So, what you do is, you get all this value and effort as an input and then…
Hannah:
Yeah.
Daniel:
Compare that into the strategy that you’re setting out for your company right now?
Hannah:
Right. Yeah, spot on. Yeah.
Daniel:
Perfect. So, let’s try to talk about delivery itself. I mean… As you’re moving forward and you try to develop these new features and these new things, what kind of inputs do you seek from customers?
Hannah:
From the customer side, if there are specific things that we’re looking to develop, we’ll send them a kind of a set of features that we’ve already defined. So, I think it’s… We try and get that balance between, like I explained it earlier, kind of understanding the use case and the problem sets of the customers, but we feel very much like we should know how to deliver that and we choose how to implement it. So, we’ll very often put a set of features out and ask the customers to prioritize them and that helps kinda give an understanding of kind of which are important and which aren’t. But also, again, we have an open discussion with them kind of through that system and through a customer success team as well. So, we can kind of really validate and understand kind of what we should be building.
Daniel:
Right. So the design per se and the development processes isn’t really taking cues from the customer at that stage. It’s mostly on the defining what to do. And then of course, when you ship it and then you start hearing from feedback, right?
Hannah:
Yeah.
Daniel:
Okay, perfect. So that brings me to, to the issue of, okay the product is running and we’ve already talked about, a little bit about this, but you get a lot of unsolicited feedback and things, you know feature requests and all that sort. But, there’s also looking at things that may not be stated. Looking at metrics, maybe trying to find out through other channels, what customers are or aren’t liking. So, let’s start with the metrics. What kind of thing tells you that a given feature is being successful or not?
Hannah:
Well obviously we track all kind of the usage metrics for every customer. I think most people do it now by kind of default I guess. And what we do is, very often with our product people start using it to solve one specific problem. So, we make sure that they’re successful and engaged with that first and again we track that through usage and through customer success team. And then we start to kind of introduce other elements of the system to them. But again, the main one is just tracking usage. We’ve got metrics all over the place, got a little dashboard we log into. We can see exactly who’s done what. We know what they’re doing, we know how many people are engaged in the organization, we know who is not using it, we know who is not logged in, all these sort of things. So, we do really just track everything to death. But generally we try and make sure, through the early stages, that we are building stuff that’s really gonna work for us. Do you know what I mean? We try very hard to avoid, it’s not always possible. We try very hard to get it right upfront and not be building things that people aren’t gonna use. Some of it’s gone wrong somewhere doesn’t it? If you get to the stage where you’ve delivered something and no one uses it, some thing’s gone wrong kind of not when you’ve delivered it, but from the very beginning.
Daniel:
Right. Yeah, I see.
Hannah:
Get the first bit right.
😀
Hannah:
Not always possible, that’s difficult but… You know what I am saying?
Daniel:
Yeah I do, I do. So, so at this stage when you’re doing the thing’s out, what you’re looking at is mostly usage and try to see if the engagement level is up to what you expected and maybe try to figure out adjustments or improvements that could be done in order to maybe try to move the needle on the usage and engagement part?
Hannah:
Yeah I guess. Yeah, that pretty much sums it up. I mean, luckily we’ve not identified problems with the usage bit, yet. I’m sure we will. On our last product, when we had kind of a lot less data to go on less information, I’d say we struggled more. But yeah, I guess the key things are looking for usage, but not just usage of an individual, but across all the users in the organization. Making sure everyone’s getting engaged. And I guess if then… I mean, the other thing we do actually, which quite interests, is when we do release a new feature, we try and kick off a little, kind of like outreach and a little content marketing campaign around that as well, 'cause what we do with our product is quite new and different, we have to go through quite an education process sometimes. So, we are wary of that and do kind of try and build the marketing and the customer success around new features.
Daniel:
Right, but I would say that since your product is something that cuts across the organization, you… What you’re looking at, and when you say that you are looking at engagement on a global level, you’re probably just looking at how are you delivering your value proposition right? So that’s… You’re making sure that the thing that you are proposing is actually being taking advantage of, right?
Hannah:
Yeah, definitely. And I think just keeping things transparent and communicating well helps us a lot as well. We’ve got this little piece we’ve done recently, called the user engagement email, and the tap of a button it goes out to our entire customer base. It tells them what’s been released in the last 30 days. It tells them what we’re working on. It tells them what other people in their organization feel is important and it gives them their kind of feedback and features with all their priorities, and ask them to kinda go back in and review those. So like little pieces like that we’re working on all the time. We’re always thinking about how we can drive engagement up. 'Cause for us with our project engagement is value. So, yeah, we’re always trying to think of neat ways to do that.
Daniel:
Right. I wanted to dig now into a subject that you’ve touched also on your blog, which is, I would call it knowing what’s noisy and what’s signal. And you talk about problems that free-trialers bring when you look at the things that they’re asking but also the value that they can provide, and also about your silent customers and the ones that don’t say anything through your usual channels. So, let’s dig into those two. First, let’s talk about free-trialers, which is I think it’s a very good distinction to have. So, what kind of things do you look, and what kind of things don’t you look when the feedback comes from a free-trialer?
Hannah:
I guess the main point, and the most important thing to do, is just separate them. There’s a lot of people who just don’t do that and that’s not helpful when you get that noise and that excuse. So separating them is the best first step you can do. I think… So, free-trialers have a lot of value to add, but you’ve got to remember that the people who sign up free trials despite your best efforts, despite your marketing, your positioning, they’re not always a good fit for your product. So, separating out their feedback, you can very quickly understand which feature was a completely oddball, and probably won’t ever go into web purely because that person isn’t a good fit for your company. But, again, because we’ve got this open channel, if there are requests and feedback in there, they are reviews. They very quickly get voted up and prioritized by all the trialers and customers.
So, it does help give us a bit of signal. We’ve got this report where you can see where it segments out just the free-trialer feedback with the prioritization on there. So you can understand what that group need, and if that matches or aligns with kinda your strategy or what your customers are asking, then it might be one worth doing, but it’s also just a great basis for discussion because we know what’s important to them and kind of what they need. We can, customer success-wise and sales-wise, can ring them up, we can say, “Okay, you’ve requested this of our product, can you tell me a bit more why you’ve requested it?”
And it just helps facilitate that discussion and helps us kind of understand whether we’re gonna be a good fit for each other. And similarly as well, when we release features that a trailer is being engaged with, they get like a little email notification, 'cause you know if no people try your product, and it could be six months when they buy, but getting them engaged with what you’re doing from a product point of view is great because they can see progress, they can see development, and then you can keep them updated as well and we often find people come back when they’re ready. Often off the back of an email that says, "Oh this feature’s being released that you asked for. " So, I think the great wealth of a great data source certainly… And there is a lot of value in there, but you just gotta be careful not let their input skew everything else 'cause, like I said, it might not be good fit. You got to account for that.
Daniel:
Great. And moving on probably maybe a little bit to the side of silent customers.
Hannah:
Yes.
😀
Hannah:
My favorite topic. Yeah, yeah. I’m so impressed you read that.
Daniel:
I did my homework.
Hannah:
I’m so impressed.
😀
Daniel:
So… Okay, tell me a little bit about this kind of customers and how can you try to engage them?
Hannah:
I think that was a learning from our last SaaS company, as I said, that it’s kind of what I was talking about before is that you get people on support going, "Oh, this, this, this that and the other… " And they’re not always valid reasons, as we all know. And then, like say, through sales or customer success people give you the big features like the top three things. If you say to people, “What do you want in our product?” Is the top, like, it’s big things. They don’t say, “Actually, on a day-to-day basis it really niggles me that this kind of button’s in the wrong place.” And just having that open channel we’ve found that there’s this whole group is silent customers that wouldn’t complain. Who wouldn’t really particularly kind of suggest anything useful when we talked to them, but just having an open channel like through all that suggest feature or give feedback just really kind of stirred up a big base of customers we’d never heard of before. It was like, “Wow.” So I think there’s a lot of value in companies giving an open channel that’s separate from support and separate from customer success, 'cause you find out all sorts.
Daniel:
Right. Well, the question I would have is, do you see any difference in terms of engagement or in terms of how they relate to the product when they are more vocal in the positive and in the negative side of things?
Hannah:
I think previously where we were selling to kind of SMEs, it was like a different user base of selling to our last company would certainly find that the most vocal users and customers were always the ones that were paying us the least. I don’t know if that’s a common thing. It’s kind of interesting, but that’s certainly what we used to find, whereas now we’re B2B but in a different space. It’s like we’re working with the people who are used to buying software and know about software. So, it’s very different. So, in this company, no I’ve not noticed anything different particularly but certainly in the last one we did. The louder they were the less they wanted to pay us. There you go. 😀
Daniel:
Great. So, we’ve touched a lot on things that I wanted to go over with you, but besides your own products, besides your own way of handling feature requests, what kind of system do you have in place to organize all this feedback that’s coming in? It might come in through either metrics, maybe customer support, maybe some interviews. Maybe… Lots of different mediums that might be producing information. Do you have any personal sort of system to organize these things and try to make sense of them?
Hannah:
I guess the thing for us is having everything in one system. So, anything. Our internal teams on our customers all have the same system for feedback and prioritization. So in that sense, that’s all taken care of. But in terms of tracking of the metrics, what else do we use? We use ChartMogul for the SaaS side, for tracking all that financial metrics and stuff there, that brings some interesting bits and pieces out, so we do keep a close eye on that. We’ve also got, we use Pipedrive for sales stuff, so we’ve got another little separate place where we drive metrics. But, generally, everything goes into one… Anything feedback and feature request related all goes into one place, because we’ve dealt with that before where you’ve got spreadsheet, you’ve got emails, you’ve got customers on Slack. Wherever else, so we’re really keen to have it all in one spot. Otherwise, you get in a muddle. So we tend to keep it in centrally.
Daniel:
Good. So, let’s switch gears a bit and let’s talk about other teams. There are two main issues that I’ve seen from product managers, which are related to, first, not having access to the customer. Maybe the customer-facing team is giving them a filtered view of what’s coming in. On the other hand, these teams are also not informed of what’s going on in the product organization. You tried to approach that using your own tool, but can you walk me through your workflow and your meetings that you might try to do, or maybe some sort of coordination between sales and customer support and product so that they are on the same page in terms of what both the customer wants and what it’s being worked on?
Hannah:
Got you. From a software point of view, as you mentioned there, all teams have access to this one thing. Everything from sales goes in, everything from customers, it’s all in one place. And we also expose the release log to sales team and customer support and everybody. So everybody can see roadmap, everyone can see releases, which is great for sales 'cause they can just click a link and go, “Oh, look, that’s what we’ve done. That’s great.” So they know where it’s up to. So that’s how we deal with it software-side. But as you say, we do have regular meetings with the team at least once a week. We get everyone together and we get a little report from each team, and again, all this is done with the view of the strategy that we set. Which again, we communicate regularly to team. But it’s basically talking to each other, we just make sure that there’s always that open communication. We never want to get into the situation where sales are off doing one thing, customer success is doing another, and product’s trying to pull it all together. So we’ve been really conscious from the very beginning of making sure that we communicate really coherently through access to the central area with the releases and roadmap, and through kind of regular meetings as well.
Daniel:
Great. So, you tried to drive, which are the most important things for all those teams in that meeting. I mean, is it the point where you clear up any thoughts, any comments that people might have on what’s being shared your on internal tool?
Hannah:
Yeah, definitely. Definitely. We’ll get an understanding of kind of from the sales point of view what the top objections we’re hearing, where do we think the product needs to go, and we think about strategy and we align that with, kind of what our current customer-base needs. Again, I think it’s just about making sure you communicate well and give people that forum and that place to discuss those things openly. So yeah, that’s what we’ve tried to do.
Daniel:
Okay, so we talk a lot usually in the positive side. “We should do this, we should do that.” What kind of things would you say that we shouldn’t do?
Hannah:
Oh, my God! How long have you got?
Daniel:
Go on, yeah. We’ve got time.
Hannah:
Oh, my goodness. Okay. So I like to think I’ve learned these lessons, but from the early days, let me have a think. One is getting pulled around by what we call a “whale customer”. So, again, early on, in the last business, we’d landed a big customer. We ran around after them, built a load of features they wanted, and we weren’t charging them enough, and then they left six months after that. So, you’ve got to not run 'round after one person, but balance their needs against your strategy and against what’s best for the whole customer base. And it is very easy when you’re getting started to get dragged around, I think, which again, is the whole, that’s why you need the data, isn’t it?
So watch out for “whale customers”. It might be exciting, they might be a big customer, but don’t run 'round after them at the expense of your strategy and the rest of your customer base. That’s stupid, as we learned. 😀 What else have we learned? Voting for stuff is rubbish. We used to just have a spreadsheet with feature requests and feedback on and every time we heard them, we’d just do like a plus one on the spreadsheet. How useful is that? The answer is not very at all. 😀 'Cause if you don’t understand the prioritization, and if you don’t understand who those requests have come from, and that all-important “Why?” then it’s useless. You might as well not bother basically. So that’s another lesson we learn that counting votes of features is not a great way to build a product.
Hannah:
And I guess, maybe the third big lesson is making sure you’ve got this data from your teams and customers segmented and prioritized. Otherwise, when you get a really demanding salesperson or if there’s someone else on the board that, “What’s this doing?”, and “it’s really important” and blah blah blah blah blah. If you haven’t got any data to back that up, you can’t have the confidence to tell them no. And that goes for customers as well. If you’ve got data in place, if you’ve got a strong strategy and understanding of where you’re going and you’ve got data from all these different groups of stakeholders, you can have the confidence to say no. It doesn’t become an issue anymore. They can see why it’s not important. They can see progresses being made and they understand why you’re building what you are. So that would be my… May as well make sure you’ve got the data in place to not get kicked around by a loud customer or a really annoying sales… I don’t know why I keep mentioning salespeople. That’s the one we hear a lot. Yeah, does that help?
Daniel:
That’s extremely helpful, yes. That’s the kind of thing that I’m looking at 'cause there’s also this thing about trying to talk about, “Oh yes, these are the good things and we don’t see why the good things are good.” So…
Hannah:
Ah! I like it. I like it, that’s great. No, it’s so true because although… I mean those three lessons, they sound really simple and really obvious to me now, but when we started off on our first SaaS product, those things weren’t obvious. I know it sounds really… Well, it makes me sound like an idiot, but I think when you’re new to it, those things happen a lot and it’s very, very easy to get pulled off by it, like wrong direction by certain people. So…
Daniel:
Right. Beyond these three recommendations and things not to do, anything else that you might want to recommend to sort of wrap this up and say to new product managers that are trying to make sense and use customer data?
Hannah:
I think the biggest thing is just understand who your stakeholders are, realize that your customers aren’t just one group, it’s not just customers, there’s groups within that, and just make sure you bring in the data to the table in terms of decision making. So if you’ve got no data at all, like in the old days product management decisions were based on kind of gut feeling, a lot of incomplete information, a lot of, “Oh, I hear this all the time, so therefore I must build it.” So collect and understand that data, it’s… You’ll be surprised what you find in it. Notice I don’t think any single one person, particularly not the product manager, can ever have all the answers. So you’ve gotta collect the data and look at it. Make decisions. Data doesn’t tell you what to do, but it informs your decision. When you’ve only got so much results to build a product with, you need to make sure that everyone in your team is building something that’s gonna add growth. You’ve got to do that. So get data. That’s the answer, get data. 😀 I’m gonna get it tattooed on my knuckles. 😀
Daniel:
And going back to our previous exchanges, I would say that it’s not only just getting data, right? It’s getting the data in the proper context. So when you say data and the things that are valuable to you, they might be different at different stages.
Hannah:
Oh, yeah. Yeah. Yeah, yeah, yeah.
Daniel:
So how would you characterize, how would you describe the data that you’re after? What’s good data to you?
Hannah:
Okay, so the good data is understanding the prioritization of things and who that’s come from. They’re the two big things we look at. But as you say, those things within that will change depending on what your strategy is. So, I guess it all comes back to understanding your strategy. Say a lot of product managers it’s very easy to do the day-to-day stuff. A good tip is, I think, a lot of people operate on a day-to-day basis. I think you should try early on, I know it’s difficult, but early on try and understand things from a business perspective. So understand the strategy and where the company is going and why and that really helps inform your decisions around the product. So yeah, always be thinking about like, yeah, there’s all the day-to-day stuff and loads and loads of stuff going on, but always kind of try and frame your decisions from a business point of view. It takes a bit of practice, but it’s really important to do.
Daniel:
Great. I guess this wraps it up. 😀 Once again, really, thanks a lot for your time.
Hannah:
Lovely! Thank you so much.