How do you deal with feature creep and avoid shipping a feature set that is too narrow in its application, is not in high demand, and doesn’t generate enough customer base.

I'm really proud of the way our product management team has gone about this. We're really lucky at QuickBase, and most SaaS platforms are, because not only do you have all the input from customer success and from your customer advisory council and from salespeople and from market analysts and so on and so forth, you actually can look at how people are using the platform. You can see it because the data is all instrumented, which is awesome. The challenge is however, you have a ton of data to sift through and you've got to ultimately prioritize it.  The team has done a very effective job. They've built a QuickBase application that basically starts taking all that input and then what they do is, based on these problems, they try to delineate. Let's say it comes to 20 problems we aspire to solve. Then you have to stack rank, what are the 20 problems that you want to solve most acutely? And how do you do that? If you think of those as the rows in our table and our QuickBase tab, then the columns are really a view on what we think are the biggest priorities in the next year or two. We think about things like if expanding in the middle-market and above is a bigger opportunity for us, or are we really focused more on small business, or would we rather think about accelerating our growth in this segment. And we do this regularly, we ask ourselves, okay, are these still the right criteria based on the business strategy that myself and the rest of the senior leadership team have come about. Based on those criteria that we define, we then have a sense of, okay, these are the factors. And then we go through a robust discussion of how you weigh those factors, followed by a robust sort of evaluation criteria type discussion where we'll take this specific requirement and score it across these five factors that we've defined. And then let's debate. When that weighted average score comes out, let's really debate. Do we feel right about it?  You get to a place where you have a stack rank and then the line comes into place. The line is basically the cut line of, we have resources to reasonably commit to the stuff above, and we aren't going to be able to do this stuff below. You have to decide what's going to make the most sense and you have to be pretty ruthless about it because otherwise you really end up in a world where you're peanut buttering and you're dabbling, and you're not really sort of creating the breakthrough of innovation that customers care about because you are halfway on a bunch of stuff. You ultimately have to make decisions that serve the best interest of everybody in an impactful way. And that's going to mean some other thing that is also really important, we're just not going to get to it. We'd rather do one thing well than two things poorly. At an annual user conference, one of our customers pulled me aside and she said, “I heard about these announcements, and I'm really disappointed. You chose to do this.” The feature set was in the area of making end users' experience with QuickBase more visually delightful, easier to use all that kind of stuff. I was able to explain that we thought long and hard about it. The tradeoff was between getting a feature that makes your experience as a builder better, or making an experience where you can deliver something that your user is more delighted with. On the margin, it's a tough call, but I'd rather have a builder be in a position where they may not have what they want for your job right now, but where your users love what you deliver even more. And she was, she was like, that makes total sense. I totally buy into that. I'm really happy you made that choice in that way. It just reinforces the importance of always talking to customers and explaining what you're doing and why. Product management is a really hard job. You're making really hard decisions, prioritization, trade offs all the time. And you know, nobody's going to be happy all the time. I've found that the best way to address that is to try and build as many relationships as you can to just get feedback and tell people why you're making those decisions. Because by and large, they're going to give you a really good insight as to, “okay. I understand the tradeoff and I do it the same way,” or they'll tell you, “no, you totally missed the boat,” in which case that's a different problem.

Anonymous Author
I'm really proud of the way our product management team has gone about this. We're really lucky at QuickBase, and most SaaS platforms are, because not only do you have all the input from customer success and from your customer advisory council and from salespeople and from market analysts and so on and so forth, you actually can look at how people are using the platform. You can see it because the data is all instrumented, which is awesome. The challenge is however, you have a ton of data to sift through and you've got to ultimately prioritize it.  The team has done a very effective job. They've built a QuickBase application that basically starts taking all that input and then what they do is, based on these problems, they try to delineate. Let's say it comes to 20 problems we aspire to solve. Then you have to stack rank, what are the 20 problems that you want to solve most acutely? And how do you do that? If you think of those as the rows in our table and our QuickBase tab, then the columns are really a view on what we think are the biggest priorities in the next year or two. We think about things like if expanding in the middle-market and above is a bigger opportunity for us, or are we really focused more on small business, or would we rather think about accelerating our growth in this segment. And we do this regularly, we ask ourselves, okay, are these still the right criteria based on the business strategy that myself and the rest of the senior leadership team have come about. Based on those criteria that we define, we then have a sense of, okay, these are the factors. And then we go through a robust discussion of how you weigh those factors, followed by a robust sort of evaluation criteria type discussion where we'll take this specific requirement and score it across these five factors that we've defined. And then let's debate. When that weighted average score comes out, let's really debate. Do we feel right about it?  You get to a place where you have a stack rank and then the line comes into place. The line is basically the cut line of, we have resources to reasonably commit to the stuff above, and we aren't going to be able to do this stuff below. You have to decide what's going to make the most sense and you have to be pretty ruthless about it because otherwise you really end up in a world where you're peanut buttering and you're dabbling, and you're not really sort of creating the breakthrough of innovation that customers care about because you are halfway on a bunch of stuff. You ultimately have to make decisions that serve the best interest of everybody in an impactful way. And that's going to mean some other thing that is also really important, we're just not going to get to it. We'd rather do one thing well than two things poorly. At an annual user conference, one of our customers pulled me aside and she said, “I heard about these announcements, and I'm really disappointed. You chose to do this.” The feature set was in the area of making end users' experience with QuickBase more visually delightful, easier to use all that kind of stuff. I was able to explain that we thought long and hard about it. The tradeoff was between getting a feature that makes your experience as a builder better, or making an experience where you can deliver something that your user is more delighted with. On the margin, it's a tough call, but I'd rather have a builder be in a position where they may not have what they want for your job right now, but where your users love what you deliver even more. And she was, she was like, that makes total sense. I totally buy into that. I'm really happy you made that choice in that way. It just reinforces the importance of always talking to customers and explaining what you're doing and why. Product management is a really hard job. You're making really hard decisions, prioritization, trade offs all the time. And you know, nobody's going to be happy all the time. I've found that the best way to address that is to try and build as many relationships as you can to just get feedback and tell people why you're making those decisions. Because by and large, they're going to give you a really good insight as to, “okay. I understand the tradeoff and I do it the same way,” or they'll tell you, “no, you totally missed the boat,” in which case that's a different problem.
1 upvotes
Anonymous Author
Learn to say ‘no’. When it comes to technology, one of the most dangerous words is ‘just’.  As in “can’t we just add this minor feature?’.
0 upvotes
Anonymous Author
I often refer this to as “talking to the market”. In early phases, it is important to deliver a core set of feature for a few customers, with a slow ramp to 10. The customers should be space out in adoption and lots of time should be spent getting feedback. This will guide your development and you will find yourself being told what to build. As you continue to grow, building a community with your customers is key. Reach out and ask what else they might need. Use marketing tools and sales staff to reach out to people who do not adopt to find out why. Train your support staff to identify problems that are features/capabilities that do not exist and flag them as opportunities. Or as I tell entrepreneurs, I always prefer to sell what people are buying.
0 upvotes