[Podcast] Good Problems vs Bad Problems

There are problems in every business venture.

But how do you know which are “good problems” and which are “bad problems”?

Jon and Nicole discuss their experiences with each and how to accurately address them on this episode of Shape the Conversation.

Show Notes

There are good problems to have and then there are bad problems to have in the business world. Jon and Nicole recognize the problems that they faced when starting a company and talk about topics like:

  • - Differentiating good problems from bad problems
  • - How to properly address bad problems
  • - How to build off of good problems
  • - Taking a problem and turning it into a solution
  • - Other members of your team will view problems differently

Best advice we have is to remember problems can lead to opportunities.

Do not look at problems as failures, instead recognize the opportunity for growth that has been put in front of you and your company. To overcome problems, good or bad, shows that your business is mindful of its customers, has the ability to persevere, and is open to change.

About the Hosts

Nicole Mears

Nicole is a former PPC analyst, department head, and product manager. She focuses on marketing and customer success.

Jon Davis

Spent years as a PPC consultant and agency analyst before focusing on making software.

Transcript

Jon: Hey Nicole Nicole: Hey Jon. J: All right, ready to record another one? N: Yep, let's do this. (music) N: Welcome to Shape the Conversation. I'm Nicole. J: I'm John. And we are working on a better intro so hopefully in the episodes to come we're gonna have this a little more dialed in. But we both work it shape.io. Nicole runs Marketing, Customer Support, a little products. I'm lucky enough to be the CEO and this week's topic we're going to talk about "Good Problems vs Bad Problems" and how they can help you decide where to put your attention throughout your day and what to work on especially, maybe, if you're building something new or starting a company. Kind of deciding what's a good problem and what's a bad problem can really help you work on things that are going to make the most difference so. Nicole describe to me what do you think a good problem is? N: Okay so, here's what I'm viewing as a good problem. We live in Bend Oregon. We have a ton of breweries. You go to the supermarket. You have hundreds of beer options to choose from a good problem for me is not being able decide which beer to take home. Is that kind of what you're talking about? J: While I agreed that is a good problem and one I often find myself faced with too at the store. That's not exactly the way I think will position this is like good vs. bad problems so here's an example, early on when I was pitching to investors 3-4 years ago and we were trying to get some seed funding investors would look at a pitch deck and they'd say like, "okay I see the plan about how you can get to, you know, 50-100 agencies using your software. But how are you going to get the next 200, 300?" And in my head I was always kind of thinking, that sounds like a good problem. Like I feel like okay get me to that problem and maybe I'll figure it out from there. So a lot of times early on when we were trying to figure out what to do we needed at least some kind of general framework to help us with priorities and figure out what to work on whether we're building features or taking new sales actions. So we talked a little bit about to how we look at that today and how determining if something is a good or bad problem determines the positioning on our priority list. So let's talk about the ultimate bad problem that we put first and foremost above all other priorities when it comes through and you know a lot about that one. N: Customer support J: There's no top priority that comes above somebody submitting a bug or an issue that might have or confusion with the app. We try to get on that one really quick so there's a lot of obvious reasons you might put customer support first but from your perspective Nicole why is that a problem that is so important so immediate when there's so many things you could be doing? N: I mean our customers are our lifeblood. We need to make sure that we have really good customer base who understands that we're there for them that we are going to take care of their issues especially when you're dealing with type of customers that we have who are typically advertisers or agencies. They're typically handling their own money or their clients money. So it's really important that when issues pop up that they see are impacting that spend that we get on it. J: And I think that may seem obvious but important to talk about a lot amongst your team and make sure everybody knows that. For example if our developers are heads down on some new feature or working on something additional to the app they know they could be completely pulled off for days at a time that there's a support request that needs addressing. So it's just part of our culture and in order for it to become part of your culture you gotta talk about it a lot. You've got to make sure it's really clear around the office everybody knows like time stops when we see that support channel blow up in Slack and somebody needs to be getting back in touch with them as soon as possible you do a great job of that but that that's one of those things we always talk about. We need to talk about all the time with our teams and with our customers make sure they know we're going to be there. N: Now I'm going to be a little contradictory here because I think yes support is typically a really really bad problem. It is going to impact your entire workflow. But there are some good instances that I see coming from our customer support or good problems if you will. And that's typically when, and I love these tickets when they come through, but when our customers come to us and ask, "Hey is this feature in here or have you thought about this?" and we get to say, "You know what, it's not in there right now but let us talk to our developers. We're going to go back. We're going to evaluate it see if we can get it in the product for you." And one I mean it's an opportunity when our developers can slot it in to really delight the customer. But two it also means that they're using the software and they're loving the software they want it to be even better. So I think good problem bad problem here is a great framework for this but I would argue that it can be both ways. J: Honestly it's kind of the original good problem. You know like I first didn't figure out what kind of customer support software we'd be using or whatever. I figure like okay well if I have customers with support tickets that's a good problem. I'll figure it out from there. That's a great example one that like, kind of starts as a good problem you don't have to worry about right away and then eventually figure out as it actually becomes a problem. I think that's the key here thinking about good to bad problems what is actually a problem right now in your day to day or as opposed to what is a problem you can maybe put off and still be okay still be pushing the ball forward and dealing with more pressing problems. N: So do you have an example of that J: One particular example I could think about was, shape for a long time was not a great experience for teams to use. So for the first 3-4 years that we were out there as a free product it was great software for somebody use individually and to set up all your data and manage as much of advertising accounts. But it was not created making it easy to share that data. N: So to give you an example before I came over to shape I was actually managing a team that used shape while everyone had their own instance of a shape account I couldn't access any of my team's accounts so I couldn't see how their clients were trending. I couldn't see if they had specific performance metrics. And so while it wasn't necessarily something that we couldn't overcome it was frustrating. J: Yeah I mean it sounds ridiculous right like you're going to go sell software targeting teams of analysts and your software is an optimized for teams but that's an example of one of those good problems we categorized as a good problem so early on it takes a lot more work with Google API as authentication to create an environment where you can share that type of data. It would have been months and months of development at a time when we weren't even sure if people were going to use the software and found a lot of the core features useful really early on. So we made the decision that hey let's first get teams really interested in using software and if we can infiltrate teams even if we're not optimized by teams then we feel like we're really onto something and we had people hacking all sorts of ways to use it. We had people sharing one log in amongst 10-15 team members who we saw a bunch of different ways that people were using the software in a team like fashion before it even existed. N: So do you think there was anything that came out of seeing people use those hacks or etc. that you actually implement into the product that you wouldn't have had you tried to build teams right away? J: Definitely there is a few things that bubbled up and without going too much in the weeds around specifics. Most of it around like permission levels. So one of the biggest things you got to figure out when you do add sharing features is, okay what is everybody going to be able to see. And that was what we were really able to mine our current customers and asked them what permissions various analysts or account managers or CEOs or CFOs were going to need to talk through and kind of delaying that decision made us develop a better product once we actually released it. Now I think it's important to say too, like, this is just what we did. This was not necessarily the right thing to do or the correct thing to do like there is a world where, or a version of this world where maybe we build those sharing features early on and it helps us spread amongst teams a lot easier and that is the catalyst that gets us going. Like I could see that also working but at the time we weren't even sure if teams would use it. So it made more sense to us let's figure out that problem down the road. N: Absolutely. J: I think there's a lot of ways that, you know, we've looked at product in this good versus bad framework. One example we just hit recently is one way we're looking to like process really large accounts and that's another challenge that now taken on as we have prospects and customers that are a little bit higher up the food chain in the advertising world. N: So when you say big accounts just again to give an example are you talking about let's say a client comes in and they have one massive account, let's say they work for a Fortune 500 company and they've got thousands of campaigns or millions of campaigns or are you talking about a big agency with hundreds of clients and then those hundreds of clients have hundreds of campaigns or thousands of campaigns. J: So I think just talking about like big campaigns however they might come and for our customers like Fortune 500 companies are sometimes hidden within our customer accounts. We might be working with the digital marketing agency that represents a Fortune 500. So bringing this into the good/bad problem framework there's a lot of things you decide with your product early on about how it can scale. So as you go through different life cycles of your product you scale up and make it more able to handle bigger and bigger accounts. And these are problems I don't think you should solve from day one. A lot of companies sit back and they say, "Okay if we put up our sign up page for our free beta and the biggest advertising agency in the world tries to sign up the next day and our software doesn't work, that's terrible. We'll never be able to bounce back from that. We shouldn't do that because they'll never trust us again." That's actually not the case. You know I think you don't even know if you can attract their attention yet. So we really paid a lot of attention to the type of prospects we were talking to along the way and the customers we were getting it kind of scaled up our services as our customers mature and we mature. And so now we're able to handle massive accounts from any company in the world whereas even a year and a half two years ago we weren't able to scale that size because we didn't have to yet. And I think product is where it does fit really well to kind of look at this good versus bad problem framework. I mean when you're trying to make recommendations into the engineering team how in your mind are you kind of looking through the sifter about what to put in front of them? From what you're hearing and support. N: Yeah I mean again it comes from a support basis so I think sometimes that does take precedence although coming from a product background I tried to really try to take all of my previous experience to make those recommendations. So again the things that are impacting either potential revenue for our clients or even ourselves. Now that's really going to take precedence again. I mean especially with a negative experience for our customers because again... actually I should say coming from a marketing and customer service perspective you have one client with a bad experience and they're going to tell 10 people you have one client with a great experience. They're going to tell two people hopefully. All right and so you kind of have to balance that. It's hard because there's times when there are small un-usability things or really great enhancements that I want to recommend being a former user of the software or maybe even hearing it from a couple of our customers. But those are going to have the same impact that something that's impacting customer support or creating customer support issue is going to impact or affect our software. J: You mentioned look at it from a marketing perspective and looking at this like good versus bad problem framework. Marketing and sales is a lot less cleeeaaar of lines when it comes to figuring out what's a good problem and a bad problem is. So example like your sales reps are always going to want more leads. They're always going to deem that a bad problem not having enough leads. So that's an example though of a bad problem in sales and marketing where you can't necessarily take action on something that vague all the time every day and you've got to decide in sales and marketing a little bit in the gray areas about what to work on and what not to work on like trying to determine what you put on the home page your website. That's very much not a problem that's ever done or ever people will agree as a whole is done. I mean we've always struggled with kind of like what to present to people on our home page and the language that resonates. N: You know kind of that unique value proposition it could seem like a bad problem to not be 100 percent confident your unique value proposition. But John said that's always going to change especially if you're a software company that's really focused on development as opposed to stasis you always want to be looking at how to improve your product for your customers and not having a unique value proposition that's static is...and here, here you go. Here you have that divide. Is it a good problems is it a bad problem because I don't know. J: Yeah and I think that's where every framework breaks down at some point you know you're just trying to look for some ways to help you make decisions through the day. So the good versus bad framework is one that we use here at shape kind of on the product side a lot of times and more organizational type stuff to determine repercussions. But the reality is you can't make every decision on that simple of a funnel and things like marketing really bring that to bear. Now I do think there are some examples of specific tasks within sales and marketing that people will take on too early because they are good problems. So example. Alright, I'm going to create a new newsletter right. And everybody that signs up for my new newsletter I'm going to create a Zapier plugin that pings it to my MailChimp list that then automatically plugs their name into the MailChimp template that gets drip to them once a week and then filters what articles they want to see like that's all stuff figure out first like, is anybody assigned for your newsletter? Just have it send an e-mail to you when you get a new sign up and put it on a google doc list and send them on e-mail you'll probably have three then four then maybe six people signing up to start. You don't have to scale those systems before spend your time on what's going to get you those initial sign ups or the initial traction on whatever marketing endeavor you're looking at. You can waste a lot of time like we probably have honestly in the past on marketing taking on some problems that were down the road more scale problems that we weren't quite at yet. N: Absolutely. So along those lines. One of those good problems that we still have 3-4 weeks into this podcast is that we still don't have an outro. We have listeners, we don't have an outro. J: That is true. That is a good problem. N: We'll be working on it per the usual along with our intro but we will be found some value right in the middle. J: And if you are listening out there don't hesitate to reach out and get in touch you can e-mail us you can email Nicole at Nicole@shape.io email me Jon, Jon@shape.io. We'd love to hear from you already heard from a few of us so we know you're out there and until next time over and out from Shape Studios in Bend Oregon.

Contact Us

Reach out to us with any ideas, questions, or feedback on the podcast!

  • jon@shape.io
  • nicole@shape.io
  • max@shape.io

Credits

This episode was produced by Max Bettendorf.

A big thanks also to 🎼 Music Flow Teaching for the intro and outro music, if you are in Central Oregon you should look them up for in-home creative music lessons.🎼)