Product Building Traps Part 1: Building features instead of improving an experience

This post is the first in a series on common traps in product building for startups. It will cover mistakes I’ve seen startups make in development, strategy and management decisions. Having observed or been guilty of all of these things, I hope to shed light and direction on what…not to do.

Disclaimer: The examples and context I will use will be from software products, but I strongly believe that these lessons can be applied to any and all products.

Contrary to what people think about product development, this post’s topic is about disassociating product development from feature building.

Feel free to take a healthy dose of skepticism along with you while reading through this post.

On the journey to product-market fit, it’s tantalizingly easy to turn features into achievements and milestones…

…at the risk of feature bloat. I’ve done this myself and I’ve seen other products do this too. When you start developing, it’s easy to build prototypes, betas and other test features on top of your main product in the name of experimentation and finding what works and what doesn’t. By all means, do it! But, then you have to let the experiments go. Don’t let experimental ideas that turn into features stay on your product if they aren’t adding to your overall holistic experience. It’s very easy to fall into the trap of pointing to all the features you and your team have developed and use that as a measure of success or maturity of your startup. It’s common to leverage your features for marketing, for fundraising or for straight up bragging about your product that’s got some ‘initial traction’. It’s tempting to take less than significant data usage on a certain feature and justify keeping it because it ‘has value’ to some of your users.

I’ve seen founders (including myself) use features that have little value to bolster a pitch to investors or win competitive deals, which makes sense in the moment. But in the long run, after accruing features on your product that have little value, you find yourself in a hole of half-baked functionality threatening the entire user experience and creating tech and UX debt that needs to be accounted for in future iterations.

Stay true to the core value add that your product gives to your users. One way to keep your experience focused is understanding your target market, knowing their workflow without you and with you in the picture. When you’re a startup, it’s more important for your survival to stay focused on the experience you’re trying to create for your users to solve a particular problem than to race towards creating as many bells and whistles that your audience may or may not find valuable. Lean on the qualitative and quantitative data to help you understand what parts of your product are actually helping you find product-market fit and what parts fall short. My suggestion? Grade your product and its features’ ability to serve your users, identify which ones are building reliance on your product and which are not. Trim the fat and you’ll find the true meaning of ‘being lean’ to achieve faster product-market fit.

By thinking ‘features’ instead of UX, you risk valuing base functionality over delight and addiction to your product

My favorite ‘building MVP’ visualization is the pyramid layers of functionality, reliability, usability and delight diagram that many of you have probably seen before.

As a quick recap, this is important because:

a) You can’t predict exactly what your product will look like since you need to have the market, data, changing tech trends, and other factors help you shape your product — so don’t try to build everything right away. Be lean, test a core MVP and iterate accordingly. Build, measure, learn.

b) If you end up worrying about building all the functionality your product needs to be “complete” too early and all at once, you may find that you’ve sacrificed…

• Usability (ie, overwhelming and confusing your users w/ the sheer amount of features)
• Reliability (ie, not building each of your features well enough to work as users expect)
• Delight (ie, not building features that your users truly feel have solved a pain point so much that they are truly engaged past their first use).

In which case, no matter how awesome your idea is, you may not get the traction or data required to keep going before running out of resources.

Most product folks get this. However, they apply it to features they build on top of a product. Does this sound familiar to anyone: “Let’s figure out MVP for this new feature so we can release it this sprint.”

Not too long ago, I was brought in as a PM for a product that was in the middle of building some initial scheduling functionality on their project management tool. Since it was going to be costly to integrate with any sort of robust calendar/scheduling service, the team decided to build it in-house. When the feature was spec’d with stakeholders and engineers, it went through rounds of ‘trimming’ in the name of MVP…which in reality was ‘what’s good enough’. It ended up being a super lean scheduling widget that allowed you to post a time, day, and some notes about the meeting on the project page. Additionally, it would send an email invite to all collaborators on the project (regardless if they needed to be at the meeting or not) with a .ics attachment. It was very bare bones.

The outcome? It killed in the sales meetings with a client who had indicated a need for it. But the usage was mediocre at best. Although I came in part way through the product development lifecycle for this work, I was definitely part of the process (read: guilty of this product trap). And in general, doing something like this can be okay. However, then you need to be good about assessing impact and iterating on it until it becomes viable…and eventually a valuable addition to the overall experience. And if not, it should’ve been scrapped. Unfortunately, it became one of a number of ‘MVP’ scoped features that added to the long, yet not so robust feature list of the platform. The company was developing product like the first pyramid above, not the second.

Using MVP thinking for feature building is all well and good to determine scope and help you release faster, but too often, this seemingly small error in thinking: a focus on building a feature instead of building an additional improvement of the entire experience can lead to a long term result of having many features..or even ‘mini products’…on your product that all functionally add something to your entire UX, but don’t necessarily delight or build reliance on your product.

Feature building can lead to targeting (and failing to adopt) too many market segments earlier than you are ready for it

Especially in enterprise products, I’ve observed how easy it is to build features for client A, separate customizations for client B and hell, let’s just build this one tiny thing for client C. It’s very easy, when focusing on features, to try to create a product that caters to many personas. But unless you have unlimited runway or your market segments are particularly small — or very similar to each other, this can quickly lead to a situation where you are essentially building many experiences for many different types of users on your one product. This could be inevitable for your industry or space, but it’s important to focus on building an invaluable product for your early adopters in a strategic way. Yes, it is important to sell and show revenue early and often. But, sell strategically. Have a plan to tackle your market so you’re not stuck building a variety of features (at the expense of an overall experience) without having the resources necessary to maintain it. If not, you could find yourself burning time and resources (and runway) trying to keep many types of users happy — and still find yourself with unhappy or not quite engaged clients because you’ve spread yourself too thin.

Feature building instead of focusing on improving a core experience as a startup can lead to product debt

If you tend to build your product by trying to optimize your pirate funnel metrics (Acquisition, Activation, Retention, Revenue, Referral) by adding features without holistic consideration of the overall experience, you risk sinking yourself under product debt. Everyone’s heard of tech debt, but product debt goes hand in hand with tech debt — sometimes it also becomes a sign of coming insurmountable tech debt. Every time you build a feature to enhance your product, you are building something that you have to work on measuring, maintaining and accounting for when defining future problems, future UX, etc. This is product debt. Not enough startups take this seriously. Product debt can lead to slowing your development down, contribute to burning your resources faster than you can afford, hinder your iterative ideation by adding more constraints, and bias your product strategy because it’s all too easy to let features inform what you should do next instead of your actual market. And of course, product debt creates more tech debt, especially in software development, so that even simple changes to your product become difficult to implement because of the various features, customizations and exceptions you’ve built on top of your core experience. It’s actually not all that uncommon to see startups get some initial traction, even multiple rounds of funding — only to experience death by product debt.

All of the above are based on my observations of product development. There are always exceptions, but if you’re finding yourself relating with any of the above (and you don’t already have a ton of users or profits), you may want to consider changing the way you think when it comes to product development. Remember, building a product means building an experience that solves a pain point. Think critically about the features you add to your product and remember that your goal is to create an experience that solves a problem, not something “complete” or “feature robust” that can do everything at the expense of actually being invaluable to your users.

Part 2: Competitive Parity as a Product Strategy

Do you find yourself relating to any of the above? Get in touch. Happy to help you avoid product traps and get you on the path to product-market fit.