As a product owner, you’ve been trained to put your users’ needs first. But you also know from experience that you don’t have the luxury of developing EdTech products in a vacuum. While your users should ideally drive everything you do, you must also contend with a host of competing pressures, from budgetary constraints to compressed timelines.
The truth is that your feature requests and production timelines are often driven by business needs. But your users are the reason you created your product in the first place. And if you lose sight of their needs, you lose control of your product.
So it’s up to you to ensure that your users’ needs are addressed without overcomplicating your product or neglecting to respond to stakeholders’ requests. It’s a tricky line to walk. However, by taking a few simple steps, you can continue to put your users’ needs where they belong: front and center.
Why User Needs Take the Back Seat
EdTech product teams never intentionally throw their users’ needs out the window. Yet there are a variety of reasons why it happens anyway. Your team is at risk of neglecting your users’ needs when:
- You start to prioritize business needs over user needs. Of course, you absolutely must tend to your business needs. But when they start to override user needs, you have a problem.
- Your team gets bogged down in a complex problem. When you get stuck in the weeds with a complicated problem, you risk losing sight of your overarching vision. When an issue starts to get complicated, you may naturally fixate on the complexities without asking yourself whether those complexities truly matter to your users in the first place.
- You assume you already know what your users want. When you create a new feature, you may have a lot of competing ideas about what is and isn’t important. Make sure you do research to determine what your users’ real needs are — not just the solution that is most expedient.
- You start cutting corners under pressure. Even the most organized and disciplined teams know something about the last-minute rush to meet deadlines. This is a time when product teams often start shedding features in order to release their product on time. The risk is that they may prune features based on time to completion rather than their relative importance to users.
How to Keep Your Product Development Process Focused on User Needs
Want to ensure that your team keeps their eyes on the prize — your users’ needs — throughout the entire product development process? Use the following tips.
Define your north star and work backwards
You’d never set out to construct a piece of furniture without first deciding whether you will build a table or a chair (or something else entirely). The same principle applies to your EdTech product. Of course, product development can and should be iterative. But you need to know what you are iterating toward.
In order to successfully tackle a new product, you must first spell out where you ultimately want the whole product to go — not just right away, but in the long run. That end goal is your north star. And if you want it to be successful, it must be deeply informed by your users’ needs.
Once you’ve identified your north star, you can start blocking out how to get there. From a design standpoint, you should plan to take a modular approach. At each phase of design and development, you’ll create designs that move you closer to your north star — and that you can later build upon as you move progressively closer to your end goal.
Develop a problem statement to drive your efforts
Once you’ve identified your north star, it’s time to develop a problem statement you can align to features and functionality. First and foremost, problem statements should define what you are trying to solve with your product, but it shouldn’t stop there. In addition, it should provide structure to your ideation efforts by describing the way your solution should benefit your users, as well as your business.
Use the following template to help your team frame up your problem statement:
Our [user] has [the problem] when [situation/context]. Our solution should [value to user] and [value to business].
As you work to fill in each blank in your problem statement, try to get as specific as possible. For example, who exactly are your users? Pinpointing that you are solving a problem for “English professors at four-year universities” is better than simply saying “instructors.”
Once you’ve developed your problem statement, your team can check its ongoing efforts against the statement to make sure that what you are creating aligns with your vision.
Let your research guide you
No EdTech product is produced in a vacuum. Your team, like every other EdTech team, functions under a number of pressures. As deadlines approach, your team likely experiences the very real pressure to cut corners. But whatever you do, don’t let your MVP (minimum viable product) become an MP (minimum product). In order to succeed, your product needs to be viable. And viability has everything to do with your product’s ability to meet your users’ needs.
You’ve done your UX research. You know what your users need. It’s your job to make sure that what you’re building meets those needs. When deadlines start to approach, use your research as your measuring stick to determine what you can give up — and what needs to stay.
More times than not you can’t build everything. Your research is your greatest ally when it comes to prioritization. In addition, consider the impact of each feature. Does the work you do for one feature have an impact in one small area of your product, or will it improve your user experience across multiple facets of the product?
The squeaky wheel shouldn’t always get the grease
When you put out a new feature or product, it can be easy to let your most vocal users set the agenda. To guard against skewed reactions, take a moment to consider the source of your feedback and prioritize appropriately. For example, you’ll want to make sure that the problems your most vocal users report are aligned with issues your other users are facing.
For a new product or feature, your upfront research should function as your main source of feedback. But once a product or feature is released, you will have multiple sources of feedback, including anecdotal feedback from your customer support and sales teams.
Rather than focusing on the newest headline of the week, consider your feedback holistically. Consider how often you are receiving a particular input and who it is coming from. As much as possible, quantify the qualitative data you receive. Otherwise, you may invest your efforts in the wrong places, especially if your most vocal users report specific needs that aren’t representative of even a small minority of users. Likewise, take care not to accept at face value the solutions that your users suggest. You must first get to the root of a problem before defining a solution.
With careful planning and a little diligence, you can ensure that your team stays laser-focused on your users’ needs — in every situation.
