This is a user generated content for MyStory, a YourStory initiative to enable its community to contribute and have their voices heard. The views and writings here reflect that of the author and not of YourStory.
This is a user generated content for MyStory, a YourStory initiative to enable its community to contribute and have their voices heard. The views and writings here reflect that of the author and not of YourStory.
Beautiful icons brought to you by 'Flaticon'
Imagine you’re a Product Manager for a consumer/enterprise product startup. Multiple feature requests come your way everyday. You groom your backlog, prioritize features, and get to the ‘design’ phase.
What happens when you don’t understand what you’re designing and not know why you’re designing?
Let’s call this mishap ‘feature ABC’
When you build multiple features like one above, your product resembles a collection of low utility features not intended for use by its target audience.
What’s your excuse?
You’ve got to be kidding if you took ‘Run with it’ quite literally and fleshed out design after design in a jiffy.
Calm down. May be there is a method to this madness. Why don’t we take a step back and understand designing features better?
From a feature design perspective, your job as a PM is to
1. Make the customers’ life easy by understanding and solving their problems
2. Know what problem to solve and design an appropriate solution
3. Comprehend the specific pain point(s) and possess customer empathy to facilitate better user interactions
After defining ‘what’ the problem is, defining the ‘why’ behind the problem is crucial to nailing the ‘objective’ of a module/feature. Setting an objective helps narrow down the scope of a feature/module. Although it is preferred to have a quantifiable objective, it may not be always possible to quantify while defining enterprise/consumer features. It depends on genre of the product (Media/Social/Storage/Travel).
Here’s what I mean,
You’re running a ‘Freemium’ Ship. You want to embed an Advertising Technology Partner’s SDK in a Consumer Media App to convert 80% of active users from (Think of Spotify) Basic to Premium.
Define the Problem
.png?fm=png&auto=format)
Flaticon
Ads to be served while an active user is viewing media content like an Audio Song / Video Song
On clicking ad, user is navigated to web portal where code can be redeemed
Convert 80% of active users
Define Why you’re solving the problem?
brought to you by flaticon
To create an Ad Platform to invite potential partners like Home Depot, Walmart, Amazon, ZipRecruiter to advertise
Revenue Stream 1: Converting Basic users to Premium users
Revenue Stream 2: Money raked in when users clicks vs engages with an ad vs redeems code..
Objective?
brought to you by flaticon
North-Star metric for this feature is to convert 80% of active users.
Challenge
To create a fine balance between serving content and ads. If the mix is in favor of ads, you’re bound to lose loyal active users over time. Merely serving meaningless ads is different from being smart & non intrusive — knowing when to serve what kinds of ads. If you’re playing ads without performing adequate research into user behaviour, it goes without saying that it does not add value to your users or your enterprise.
What makes the difference of knowing the objective of converting 80% of users?
Design appropriate email marketing & advertising campaigns after understanding user base, their listening preferences, and use their location to identify what language an ad needs to be served et al.
Understand when these emails or ads need to be timed after conducting research on UserApp Sessions and User Engagement Studies
Conduct A/B testing to validate hypothesis with respect to user behaviour and interaction
Once the feature is deployed, track the performance of conversion over a period in time and see how corrective measures can be taken and how these can be broken down into future feature enhancements
What are the ill effects of not clearly defining ‘what’ and the ‘why’ behind a feature?
Lack of Customer Empathy in UI/UX Design: Sans a clear objective and understanding of the end-user and his/her pain points, the team may keep iterating for days together with no end in sight. UI/UX design can get valuable feedback for their designs from customers/prospects. However, seeking feedback for a product with no active customers/prospects becomes tricky. Even if customers/prospects do exist, in the absence of clear understanding of the user goals, feedback from customers/prospects would be akin to waking the team from slumber assuming team is talking to the ‘intended’ customers.
Timing the MVP: When ‘time to market’ is a north-star metric and the team is trying to introduce a new product in the market, if the ‘objective(s)’ is/are not clearly articulated, it becomes difficult to build an MVP to get feedback and iterate. As a result, it gets difficult to design and develop the basic user-stories which can get you across the finish line.
Prioritization Issues: If Sales requests a feature without knowing the objective(s), it is necessary to understand if there is a workaround to meet the objective(s). If there is a workaround, knowing if the feature development is going to be used for a pilot or just a demo is crucial. If it is for a customer pilot, it may be of higher priority assuming the sales team can dance around the feature in demos by exhibiting the workaround acknowledging that ‘feature’ is in the roadmap, and will be delivered once the customer is on boarded. Due to bad prioritization it may so happen that you end up delivering a feature (with lots of scope creep) just for a demo vs missing designing another feature for actual ‘paying’ customer(s).
Sunk Costs: Without articulating the need for a feature (let’s call this ‘X’ which takes several sprints to complete) you run the risk of it getting scrapped at the last moment during development and replaced by another one (let’s call this one ‘Y’). Time spent working on defining the detailed UI/UX interactions, functional & tech design, detailed user stories and sub-tasks may not be considered an utter waste if design for ‘X’ can be reused for ‘Y’. However, in cases where design for ‘Y’ has to be overhauled and core components of ‘X’ cannot be used, as a Product Manager you’d be faced with the following dilemma: Do we go with ‘X’ due to sunk costs associated though it may not meet the end objective or ‘Y’ which means Product Launch/Deadlines have to be extended and all the heavy lifting in terms of actual design & development has to be done from scratch? Invariably, teams should perform due diligence when it comes to market research data or conduct appropriate customer discovery to avoid such an instance.
Product Marketing woes: If ‘what’ and ‘why’ are ill-defined, product marketing material may not reflect & target the actual target segment of marketing campaigns. As a result, customers aren’t aware of the existence of this new feature which defeats the purpose of building it in the first place.
Impact on Team Morale: ‘Market is evolving quickly and we have to adapt’ excuse may not go down well with the Scrum Team if the work performed in terms of QA Design, UI/UX interactions, and API design for X cannot be reused for Y, and hence design for Y has to start from scratch. As a result, the team morale goes for a toss and some PM time may be lost in damage control. Scrum team looks up to the PM team in terms of clearly defining ‘when’ to build ‘what.’
How to handle feature requests and design?
Below mentioned are some of the questions to get you started:
Does it fall well within our Roadmap of where we want to be in the near future?
What is the pain point of the customer?
Who is the end-user of this feature? Do we restrict the use of this feature to user with specific role eg: Super-admin, Supervisor, IT admin (these roles depend on the nature of the product)
Why isn’t any current feature able to solve this?
How likely is this feature going to be used?
When can this feature fail? Nail all the negative scenarios (assuming happy path is something you’ve already thought of) when a feature won’t work because it is designed that way or due to external system constraints like lack of permissions for Wi-Fi, GPS, Camera etc..
(If you’re building multi platform product), what platform(s) does this feature have to be on? Can this feature be realized consistently on all platforms or are there OS level restrictions we’ve to be aware of? (Where Platform = WebApp, Mobile, Gaming Console, SmartTV, Auto)
Do we invest time in building ‘X’ which gets us on par with our Competitors or ‘Y’ which gets us a Market Differentiator?
Due to Lack of expertise & time, do we need to partner rather than build this out ourselves? Partnering sometimes may also help you learn about how a feature is used by end-users and the best practices that the partner adheres to with respect to business process and user flows. In the meantime, your team can invest time in building something closer to your core competencies.
How are we making our customers aware of such a feature?
1. Email Marketing Campaign — Eg: Uber sends a mail to educate users about the monthly pass/flat-rate feature available in select cities
2. Push notification — Used by ecommerce apps like Groupon, Amazon to bring user’s attention to a SALE
3. In-app tutorial/wizard — Upon launching an updated app (iOS or Android) in-app tutorial is shown to apprise users of latest features/gestures that the new version supports Eg: Swipe functionality, 3D touch on iOS
When there are multiple requests coming in from the sales team — ‘how important is X compared to Y and Z that we reviewed last month?’
Irrespective of how well the user base is known, iterating by constant feedback cannot be ruled out. Above set of questions offer a framework to aid PMs steer clear of common design pitfalls by articulating the ‘what’ and the ‘why’