Here are a few simple techniques that will help you:. Although this rule is simple, it can be tough to achieve in practice. You need to identify the parts of your product the core features that provide the maximum value to your target audience. Dan Olsen, author of The Lean Product Playbook , stresses the importance of focusing on core features in his book:.
But at some point, as you add more and more tools, a Swiss Army knife gets wider, heavier, less usable, and less valuable. Focus is critical when defining a new product. Even after going through these steps, the total number of features that you may want to include in your product might be overwhelming. So, the next step is to apply a Pareto analysis. The Pareto Principle states that, for many events, roughly 80 percent of the outputs come from 20 percent of the inputs.
You might find that the numbers change slightly, but there are many examples of this ratio coming up in a variety of fields, including marketing, science, and economics. This principle can also work for product design: you need to find 20 percent of the features that bring 80 percent of the value for users and businesses.
For example, if you have an MVP or fully realized product, you can measure the adoption per feature. Create a simple 2-axis chart to analyze the adoption per feature, where the X-axis shows each feature in your product, and the Y-axis shows the percentage of customers using the feature. You can then easily see which features are the most important to your users.
The logical question then is what to do with the features that have a low adoption rate? This decision might be hard for products that have already shipped on the market—some users may already be using those features, and removing them from an existing product can be painful.
However, keeping features and bloating the product is not a good practice. Offer an alternative feature or tool if possible. These are some of the good points to start with. One of the easiest ways to get a glimpse of the market sentiment is to use SEO tools. Apart from researching the need for the feature that you are planning to implement, you might even come across search queries that will lead you to completely new functionalities.
Do a competitor analysis. Did they solve the problem that the audience has? How did they do it? Maybe they were the victim of feature creep and their interface update was not well accepted - that could be an opportunity. There is a solution to this - user testing. It is great for both the planning and development stages of your new feature.
The main goal of this is to verify that the functionality you are developing will be helpful to users and if they want it. It is easy to get distracted. Keep the main objective of your project in mind at all times. As we discussed above, the majority of users do not want an enormous variety of features and settings. When features start to creep in, get back to the data from user testing.
Do users need this? Will they use it or will it be another obstacle on the way? When fighting featuritis, one of the cures is trimming redundant things until you are left with as few features as possible that will allow the planned update to work.
It has to be forced back on course most of the way to safely land in its final destination. After you have done your research and maybe even had a chance to show the planned feature to a user testing group - solidify your plan and whenever you start to stray from it - force yourself back on it.
You and your team must know where you are going. This can be achieved only with a clear project scope. The functionalities and features, time plan, responsibilities - all this must be confirmed at the beginning and communicated to the team so everyone has the same information. If the deadline is in a week, you will most probably adhere to it.
But what if the deadline is in 6 months? The answer is - milestones. Create realistic but ambitious milestones. When the time is put on paper, there is no space for adding new features that were not confirmed at the beginning, because - there is just not enough time. To make sure that you are not creating a base for any future mistakes or limitations - evaluate all feature requests you receive before agreeing to them. Consider the difficulty, time, and resource that an additional change would consume.
Or maybe you overlooked something at the beginning and this would be a great addition. The first version of a software product helps a specific group of users accomplish one or maybe a few tasks. It solves a specific problem well. At first these improvements make sense because they represent refinements of the main idea or feature set. So you keep implementing them into your software product.
However, as the product matures, there comes a point when some features make sense for only a limited group of users. Not only that, but some initial features may no longer make sense at all. However, you keep adding new features quickly in order to keep up with pressure from your users and your competition. And since adding new code is generally easier to do than refactoring and rethinking existing code, these new features continue to pile up on top of the existing ones.
Wikipedia defines feature creep this way:. Feature creep is the excessive ongoing expansion or addition of new features in a product, especially in computer software, video games and consumer and business electronics. These extra features go beyond the basic function of the product and can result in software bloat and over-complication, rather than simple design.
One main difficulty in dealing with feature creep is that it takes you by surprise. In the exuberance of development, product owners and system architects will cut many corners in the rush to the market. This rush, however, is the perfect environment for developing feature creep. You must learn how your customers have integrated it into their daily workflow.
This can be difficult to achieve simply because useful feedback is hard to obtain when your software is just one of the many products your users utilize each day.
However, you have no choice if you want to develop a relevant product. Here are some practical ways to help you better understand how people are using your software.
There must be an easy way for users to provide feedback and request new features. So a good software product should have an integrated feedback loop. In addition to poorer usability, feature creep can cause a product to actually become less stable because of unintended results between the various components.
The term is primarily used in reference to software, but can also be used for hardware. The thing about software packages is that the software vendor needs to keep on releasing new versions in order to keep generating revenue.
It's hard to sell a new version that doesn't do "something" that the old version did not. As a result, more and more features are included even though the average user might never use them. Some would argue that "progress" is actually a bunch of unused features that make computers less stable. Windows has literally thousands of additional features and can do far, far more than DOS.
However, DOS crashes remain rare, whereas Windows is well-known for crashing on a regular basis.
0コメント