From ancient Greece to mobile product planning , the issue lingers. A fundamental requirement in the planning process of a mobile product is to know your product. This is a philosophical question in its essence; quite similar to “know yourself” which is an ever-lasting always evolving process. Putting the philosophical aspects aside, the clearer you see your product, your core, your differentiation, and your positioning, the better chance you have to attract users and become successful.
Knowing your product serves:
- Your product – it is a mature product with less distractions
- Your project – the project becomes easier to manage once the product is clear
- Your time – with less uncertainty and last minute realizations, the shorter time it takes until your product hits the market
- Your financials – a well thought and well specified product costs less to develop and is less likely to cause costly surprises
- Your potential customers – they get a service they know what to do with that answers a need they have
If you haven’t read the previous article, Tagged is an imaginary start-up to showcase the points covered by the series of these articles by mobers. Tagged service is next gen electronics and appliances insurance service. You get a quick price quote based on the devices you own, and when time comes you get an instant fixing or replacement service.
The imaginary product definition meeting
Because Tagged is an imaginary start-up, let’s assume we had an imaginary product definition meeting. The experienced team immediately started to bring up ideas to make our service one that will make an impact. We want to simplify the process, to streamline the user through the initial acquisition with no keys pressed. The user will also be able to get a real-time indication to where nearby service providers are located, to track the progress on devices they sent for fixing, and so on. Less than an hour in the meeting we already wanted real-time video processing to identify which devices need to be included, an automated scan of device and model (OCR), location based service, ticketing system with real-time tracking including GIS, and more.
The imaginary team of the imaginary start-up Tagged is obviously very knowledgeable about technologies and industry standards but the one hour meeting could eventually cost the company about 4 times the price of the actual product we need to launch with many potential pitfalls, hurdles, and time spent.
Do we really need this!?
If the product path is clear, we can easily clean all the clutter and see that our product is not about the automatic acquisition and automated pricing process. We are also not in the service ticket and item tracking business as well. The decisions about the MVP (minimum viable product) will be discussed on another article but the mindset is already demonstrated in this paragraph. If we maintain our focus on the essence of the service we can weed out many “nice to have” features that somehow get communicated by mistake as “must have” requirements. Our initial product can require people to manually choose devices and models to get the price quote and based on our mandatory SLA we can inform customers with a timer the latest date on which they should get their device fixed. We do not really need to implement the video acquisition and processing, the OCR, the GIS, the ticket tracking mechanism etc.
It was done before
I am sure the software wizards at Tagged could do a great job but there are companies who specialize in specific products and technologies and offer off the shelf services, libraries and API for many functionalities. There are OCR libraries, GIS components, and many other elements we specified that were developed and also are being maintained by specializing companies and groups. Our engineers will never be able to perform their Tagged related tasks, and still produce better results than products that are owned by specialized companies. It is not just a matter of ability but more of a price performance ratio. We do not want to specialize in OCR and we are not able to capitalize on the potential revenues from this development so no reason to put our efforts in that direction. This is obviously just an example that shows how easy it is to avoid complex projects being tangled by taking too many tasks and challenges that are not mandatory to our solution.
Know your competition
You can utilize the information you collect on your competition to better understand what your focus should be and therefore better identifying your core value and the core of your product. Nevertheless, remember, if your competition targets the same market with a similar approach, your product should resemble in some ways their product. You should be able to distinguish your product from theirs and you should have your own “angle” but the majority of the core elements will probably be very close. This can be used as a test because in most cases if your core product seems to be doing the same things (maybe differently) than what your competition does, your core is relevant to the market. That is a very important statement to be able to say about a product in its planning phase.
Prioritization of elements in your product is also a valuable tool to distinguish between your core and your features. Your core can never be prioritized as something else than must have. If you remove from your initial product everything that is not must have, you are very close to release a coherent clear product that involves less risk. In order to reduce risk in implementation, make sure in the prioritization process you dedicate a column per each element or feature to the risks and costs (resource based) involved. The risks will assist you to plan ahead and overcome potential challenges that may rise.
Becoming featureless means you do not develop or maintain features. At the early stages of your product, features carry with them risks and costs and also distract you from perfecting your core service or product. The essence of your service is your core, it is not comprised of features, this is your engine this is one unit that is crucial for your goal. The challenge is to truly identify what this core is for your company / product. When you concentrate on only building this unit you do not burden yourself caring about features and you become featureless which is as close to product enlightenment as possible. You are required to leave the emotional sentiments aside and really strip your product to its bare bones in order to achieve this state.
The guidelines to become featureless
This is not easy to do but I will try to provide a list of steps that can be used to remove features and become featureless.
- Bring perspective to your product specification meetings. The addition of business development professionals, financial professionals and other perspective less directly connected to the product will probably challenge your perception and assist you to reduce less important features.
- Ask yourself what your people do the best. Your product should be within these strengths or you should rehire.
- Ask yourself what happens if you remove each feature, if the system cannot work without it, this is not a feature it is part of your core.
- Make a research on existing solutions that can be used in your product. If you find companies that offer these abilities and are not direct competitors, good chance these are features and that you should not spend resources developing them.
- Make a weekly or even bi-weekly assessment of feature list and prioritization. Remove every feature that is not must have. Don’t worry, if you made a mistake and removed a crucial part, it will reappear very soon.
- Try to make the “technology free” version of the service that provides the same value to your customers (minus the efficiency or other aspects that were achieved through the use of technology). Your product definition should correspond directly with the offline version. In most cases everything that is not aligned with the offline version is a feature.
- Our innovation team at moblers is very skilled in isolating products and find the essence of the product. We are good at it because we have done it dozens of times with many customers and many products. With time, we became more aware of standard distractions and leeching features and with each new project we handle, we improve this ability.