Most features shipped make products worse not better. Let’s talk about how to avoid this trap.

I’ve worked on many products where many teams ship most features that make their products worse.

The problem here is we get caught in these build loops or traps because we’re not following a process to help us first identify what our customers really need.  Let’s talk about how to solve this problem.

To find product market fit faster, sign up for my free 5 day email course – https://nxtstep.io/fit

Episode Transcript
Hey, folks, sean here.

And today what I want to talk to you about is how to know which feature to design and build next into your product that’s going to offer maximum value for both your customer and your organization.

Far too often I work with clients that ultimately get caught in what’s commonly referred to as the build trap, which means that you’re continuously building and shipping features without a whole lot of understanding in terms of why.

Oftentimes this can be referred to as well as feature factories.

Your product development organization just kind of becomes a feature factory in that you’re just constantly building and shipping things without a whole lot of understanding in terms of the impact that ultimately that’s going to have on your product and its experience. Now, the problem here is if you don’t know why you’re building those features in particular, and that’s not commonly understood by your entire product development team, then ultimately you are more likely to make your product experience worse rather than better. And I often see this being a part of the problem in terms of not really knowing which process to follow instead, as it just kind of feels like you should be doing something. And oftentimes the incentives for product development teams are misaligned with making the product experience better and adding more value for your customers, which makes this problem worse as well as and you may be being held accountable for ultimately building and shipping more features, which isn’t necessarily the objective here. In fact, that, like I said before, can actually make the whole product experience worse.

So if you’re building, I want to talk to you about why this can make it worse.

If you’re building and shipping features for which you don’t have great direction in terms of the impact that’s going to have and how that’s going to make the product experience better, then more than likely your customers and your users aren’t going to need it. And if your customer users don’t need it, then when they see that feature in your product and they don’t use it, it’s going to continue to make the product experience more confusing for them, more clumsy for them.

That’s why I say it makes your product experience worse.

It’s because it’s not a need that they have. And you building those features is not grounded in anything that is particularly relevant to solving problems for your customers.

So I want to talk to you now that you have a better understanding from that perspective in terms of that trap and why people fall into it.

If any of this sounds common to you in terms of you’ve been there before, I want to talk to you about the approach we should be taking instead to ensure that we don’t fall into one of these common traps.

So what I’ve shared so far might sound great, but your next most pressing question might be, okay, well, what do we do instead?

How do we know if we’re shipping a feature or we’re going to ultimately build a feature or what we should prioritize that’s going to make the product experience better, not worse.

And that comes from discovery, discovery and also research. If it’s on the earlier stage side of your product or we’re interacting with someone who’s new to your product, I refer to as discovery that’s conversations essentially with prospects who don’t have prior experience with your product. And if it’s on the later stage side, I refer to that as research in terms of a customer or user that you may already have.

Now, I want to talk to you about the objectives when having conversations with each. But I’m going to use a framework that I call Buckets and Marbles in terms of figuring out essentially from the opportunities that we identify from investing in the research and the discovery, how do we know which one to pick and how do we continuously prioritize as more of those opportunities are coming available. So from the discovery perspective, that helps you track your market to making sure that you have a better understanding of not just where the market is, but where it’s going. And if you’re talking to prospects that are having only a very little, if none experience at all with your product, they will be telling you what is most important for them.

So if you are gathering this information and you’re tracking this information, you’ll have an idea and you could create sort of like a trend line in terms of where it’s going, which features are most popular that they’re requesting, which problems are the most common ones that they’re experiencing. You’ll be able to track that.

Now, on the other side, for your existing customers and users, if you’re interacting with them, what you’re trying to do is you’re trying to figure out how to make your product better. So theoretically here your product is already offering the value. That’s why they’re using it. But in order for them to continue to use it, it may need you to prioritize continuing to make that experience better because their needs are likely to change over time, right? The product and the market and product market fit are both dynamic concepts.

I’m talking about tracking the market so that ultimately we can continue to upgrade and improve your product. So that’s where that’s the process you need to connect to product development and that’s where all of this should begin.

That’s the catalyst for everything that gets invested in the product development process.

And if you’re not investing in either one or both of those, you need to stop what you’re doing now. Especially stop writing code. Because like I said before, you’re likely making the product experience better. And instead, invest in both of these opportunities to perform discovery and research to find a source of those problems and opportunities worth building into your product experience.

Now, the last question I want to talk about today is once you have identified a number of those problems from prospects, from customers, how do you prioritize them for development?

Well, that’s where this framework that I developed called Buckets and Marbles comes from. Essentially when I’m having these interviews, what I do is I create a bucket every time I’ve heard about a unique instance of a problem that a prospect or a customer or an existing user has or needs solved.

Every time I hear about something unique, I create a new bucket to store ultimately future instances of me hearing about that same problem. So, if the first prospect I speak with mentions two problems, I start with two buckets, A and B. If the second prospect I mention has three problems, a, B and C, I create another bucket and I put a marble inside of A and B, because that’s the second time I’ve heard about that problem.

Over time, if you follow a construct like this, you will have any number of buckets but sorted be able to be sort them by different varying weight because you have a unique number likely of marbles in each bucket. Meaning that every time a problem was mentioned and you put a marble in that bucket, it’s going to change the weight of that bucket. As such, after you’ve done your research, after you’ve done a round of research, which I would recommend you do until you stop having the opportunity to create essentially new buckets or you stop hearing about new common problems at this time, then I would sort the buckets by weight because they should all be different weight, essentially.

Now you’ve got a list of priorities that says here’s the top problems anywhere from our prospects to our customers and users are having. As such, these are the things we need to be prioritizing in our product experience. And if your product roadmap or what’s at the top of your backlog doesn’t match those problems, now you know where the disconnect is and you know how to fix it.

You need to make sure you’re prioritizing solving those problems first because that’s what’s going to make your product experience better.