← Back to Resources

Thinking to kick-start UX research in your startup? Start with features that no one uses

Thinking to kick-start UX research in your startup? Start with features that no one uses

Most startups move at lightspeed building super cool products & features. To keep up, user discovery is sometimes sacrificed to the detriment of understanding customer’s unmet needs. And, when the UX team is brought in to transform the product experience - we often discover products and features with low engagement after launch. 

Conduct a quick sanity check whenever joining a new organization, especially a startup. The goal is to identify worst-performing features and understand the business need behind building them. Oftentimes, the need is driven not by real customer insight but by intuition or gut. This helps me to reinforce the value of a structured user research process. And, ensure we build products and features that our customers would value and know how to use.

Here are simple steps to implement that will increase the chances of building a user valued product:


1. Identify your users early 

It is always hard to find the right users. So, I start by creating an unvalidated persona, which helps me to identify candidates for user interviews. Sites like Reddit, Craigslist, and Facebook groups are helpful in finding potential early adopters. 

I generally create an ad to source users. In the ad, I highlight how we're trying to solve “x” problem in a given industry. And, to filter out the poor-fit candidates, I add a survey with a few vetting questions. The last question is to ask if they’d like to be part of the solution and to please share their email. 

2. Find the most important pain point in the problem stage

Users will have multiple problems they face, it’s our job to identify the highest value unmet needs to solve. During my user interviews I have preset questions that deal with narrowing down the problem. 

I use a user story map template so I capture the E2E user journey with tethered pain points. If you’ve never used a user story map, it’s one of the best tools out there. The important part of this stage is to do a few things like

  1. Define the problem statement(s). If you have several, it’ll be best to vote on which is best to solve. A trusted approach is using a design sprint method to dot vote on sticky notes. This keeps it objective and fast
  2. Convert problems statements to “How might we” (HMW) opportunity statements
  3. Identify the users goal or “job-to-be-done” (the reason they’d hire your product)

3. Start sketching solutions as a team

With another peer(s) take the HMW statements and come up with as many ideas as you can in 10 min. Then vote on the best ideas. Take into consideration the customer value and tech level of effort to build. Take the winning idea and as a team create a three part solution. As a team, vote on the best three part solution. This is where we birth our value proposition (the answer to our customer pain point). 

We then start to wireframe the solution, which would lead to a mid/high fidelity mockup to test with the users that were interviewed. Make sure to use an affinity approach to the learnings from user feedback. It’ll help prioritize any updates to the mockup. The goal here is to know your solution is the best solution for the right user problem. This should be known before the dev team writes a line of code: Is it valuable enough to our users to build, can our dev team build it, and is this aligned with our business goal? 

Then update the mockups and redo the usability testing with users. After a couple of these you’re on your way to creating an MVP. Plenty has been written about MVPs but I really like Dan Olsen’s definition. It has to be delightful, usable, reliable, and functional. 

4. Ready to build

Once we’ve gone through problem and solution validation, it needs to be communicated to the dev team. Try to implement a scrum process early on so it’s part of the product culture as the startup scales. It’s probably best to keep it simple at first. 

  1. Two week sprints
  2. Sprint planning meeting where you actually walk through the user story and answer and get a shared understanding of what’s being asked of the dev team
  3. A structured user story that has acceptance criteria, links to design artifacts, background, tech notes
  4. Some type of QA checks and balances that’s signed off by product before it goes live to customers
  5. Identify a north star metric that measures the feature or product's success. The Pirate metrics are my favorite

In summary, talk to users early and often. Get your product management game organized and don’t be afraid to pivot if customer feedback is telling you to. Keep a pulse on customer feedback immediately after launch and beyond. Having CSAT or NPS widgets embedded onto online tools is a quick, easy way for customers to share feedback. 

It’s always helpful to read up on the latest product management and UX design trends as there are awesome pioneers taking our craft to the next level.

Keep up with the latest

Subscribe to read our unique perspective on all things user research and product feedback.
Success! You're subscribed.
Oops! Something went wrong while submitting the form.