Feature party... 💃 🕺 Whaaat?

How feature parity kills your product value  ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ Hey Folks! When I first learned about "[feature parity](" I actually misheard the term as "feature party" 🤦‍♀️ - imagine my brain's system error..."What do you mean?! Dancing tooltips? Unfortunately, feature parity is no fun and games: it is one of the most common delusions in product management - that if only you manage to catch up with your competitors, customers will magically flock to buy your product. [[Animated thumbnail for video] 👉 Watch my video-rant-on-it]( I feel like [Brandon Dohman]( said it all [in his article on that point:Â]( [Image] But before we discuss it, let's first define feature parity: [Image][Image] See. Nobody's asked little Johnny if he even *likes* blue. Feature parity is when your product has the same features either a) across all its platforms (e.g. desktop vs. mobile) and systems (e.g. iOS vs. Android, Windows vs macOS), or b) the same features as your competitors. Both types of feature parity are wrong and mostly a waste of time. Again, to quote someone wiser than me ([Brandon]( 👋): "When trying to get to feature parity, this means there is a high likelihood that you are going to build something that is Rarely or NEVER USED.​ Not only are you not providing value to your user, you're wasting 10s or 100s of thousands of dollars on development and 1000s of development hours. In this, you've managed not to make your users' life better, and you've demoralized your engineers because they never get to see anyone use their software." Remember the [Build Trap?]( [Image] But one of them is actually wong-er. Let's see why. Feature parity across all platforms - WRONG I see more and more companies trying to keep their web and mobile apps "equal" in terms of features, without any consideration of how their products are used between the two platforms. E.g. people use mobile to mostly consume and check information, but not e.g. for lengthy editing work. I'm using an accounting app that helps me track expenses, and helps my bookkeeper reconcile the transactions for my tax return later. While it makes sense for me to use the mobile app to e.g. take photos of receipts, it would make no sense for my accountant to use the mobile app to do my tax return. Similarly, Myfitnesspal doesn't have the option to scan QR codes on desktop. Because you'd never use it. Just imagine running around with your laptop, scanning QR codes... [Image] There's simply no point in wasting your development resources on building some features across all the different platforms. Now, let's look at competitive feature parity. Feature parity between you and your competitors - WRONG-ER [Image] In this case, the features you develop are not determined by the needs of your existing user base but rather the desire to eliminate the competitive advantage of your business rivals. I know I know. Revenge is a great motivation, but you ain't Shakira. To whom it may concern: this may sound counterintuitive at a first glance, but simply copying the functionalities of your competitors is never the best way to gain a competitive edge. Not even when you tweak/ improve them a bit. Why? a) if you copy your competitor's features directly, all you will be able to offer to your customers is a copy of what they are already using. Duh. Why would they go through the hassle of switching to another product? You must have heard of switching costs and user inertia, right? b) even if you improve on your competitors' features - you have no guarantee their users were actually using them/ finding value in them at all. Unless you're a corporate spy, you don't have any access to feature usage data of your competitors. Maybe these features don't really deliver value to their users and nobody's using them? Maybe they also built them because someone else had built them before? Before you decide to commit your resources to develop a feature that your competitors offer, think about the[value it will bring to your customers.]( If you’ve been in the product world for a bit, you must know the 80/20 Pareto rule. 80% of the value comes from 20% of the functionality. Many features – about 45% – never get used. It is your job to identify the 20% of features that are most valuable to your customers. If a feature released by the competitors is in that group, then fair enough, go for it. If not, though, focus on identifying other ways to generate more value. The first question you should be asking yourself to avoid feature parity is: "What are your users' Jobs-To-Be-Done?" Instead of blindly trying to keep up with your competitors in the feature-development arms race, go back to the basics and look at your customers’ needs and the goals they want to achieve. Then find innovative ways to solve their problems better than your competitors.  How to escape the feature parity trap & build features that serve your users better than those of your competitors? There are several ways how you can discover what would bring your users more value before you've committed your development resources to it: - Use your [ North Star metric]( and North Star Checklist to stay on course with your product: [Image] - Use [Opportunity Solution Trees]( to uncover the true value in the opportunity you have in mind - a model developed by Teresa Torres, a Product Management guru. Don't skip any steps and work your way down through each of the levels:  1) business objective, 2) opportunities (user pain points), 3) solutions, and 4) experiments to test their effectiveness. [Image] - Do [continuous discovery]( on your users to understand what would unlock more value for them - Use in-app microsurveys to improve your features and recruit your best users for discovery calls (hey, you can [build them in seconds without coding in Userpilot!]() [Image] - use fake door testing to test demand before launching a new feature - you can e.g. add a new page to your app and a tooltip explaining it in your dashboard, and then - when the user lands on the page - inform them that it's work in progress. This is something you can build without code in [Userpilot]( as well, but if you want more reliable results - I'd probably invest in some frontend elements of the feature you're planning to build and[tag them with feature tags]( + watch session recordings to see how (and if) the users really interact with them - being feature-curious is one thing, and actually using it - is a completely different story... Hopefully this gave you some food for thought on feature parity - as usual,[check out our full article to find out more](. See you all next week! [Image] Emilia Korczynska, Head of Marketing at Userpilot I'm a marketing manager obsessed with product growth. Wanna talk? Simply respond to this email!  To make sure you keep getting these emails, please add emilia@userpilot.co to your address book or whitelist us. Want out of the loop? Don't remember you subscribed at all? We get it. We sometimes don't remember how we got to our office today let alone how we subscribed to this or that email. Sometimes people also get offended by our strong opinions on all matters product, SaaS and UX, but you know what? We won't stop sharing them - and what we believe is the best product practices and the future of SaaS. Anyway, if you ever want to come back you'll know where to find us. Until then! [Unsubscribe](. Our postal address: 1887 Whitney Mesa Dr #9995 Henderson, Nevada 89014 United States