At Slingshot, we like to say you should “look before you leap; discover what you’re getting into” before development starts. What happens if you decide to skip research, or build on assumptions? If your product is built without user input early and often, you’ll end up with underwhelming results. Taking time to understand what problems your users are facing today and where the industry is headed, you’ll be able to build a more-successful product.
Today, software development needs a research phase to help you understand your user’s problems as well as the best way to solve them. How do you successfully complete a research phase, why it’s important, and what happens if you skip?
Summary
A research phase usually consists of user interviews, stakeholder meetings, and competitive analysis. User interviews are the most important, as you’ll be talking to the people who’ll actually use the product you’re building. This way, you can ensure that the features and interfaces are built in a way that best serves your users.
An upfront research phase can help you save time and money in the long run by discovering pivots or issues in the beginning as opposed to after launch. Since development usually comes with a large price tag, you’ll also be able to de-rick your investment. You’ll also be able to back up all your choices with evidence from your research, as opposed to opinions and assumptions.
What’s involved in a research phase?
Slingshot has been around for over 16 years now, and we didn’t always have a research phase. After years of trial and error, we’ve come up with a research phase that works best for our projects. Here are the steps in a Slingshot research phase.
1 – Identify Goals and Metrics
You should always start by finding out where the stakeholders are at. Oftentimes, each stakeholder has a slightly different vision, ideas for what will be built, and what is seen as a ‘successful’ project. We like to sit down with each person individually to ensure honesty and eliminate groupthink.
We’re also looking for the key reason(s) why this product should be built. This helps inform what metrics to track, what assumptions are being made, what users we need to talk to, and how to form an interview guide for the next step of the process.
2 – User Interviews
This is by far the most important step. By talking to the people who will actually use the product, we can uncover insights we wouldn’t have expected. We want to see the environment users operate in, how they experience the problem this product is to solve, and the pain points they experience. We’re also trying to figure out if the assumptions initially made about the problem and envisioned solution still hold true.
This again is done individually with 5-10 users. Even with the low numbers, we’re able to extrapolate results and see trends. Statistically, it’s not necessary to interview hundreds of people. Chances are if you interview 10 people and don’t see the problem the envisioned solution is to solve or see any trends for that matter, it’s unlikely interviewing 90 or 100 more is going to change much.
Based on user interviews, we may recommend not moving forward at all. It’s happened before: a client came to us expecting their users to be experiencing a problem, and after conducting a round of interviews, that problem wasn’t really anything users were concerned with. We recommended they cancel the project, and they did. We’re not kidding when we say our core value is integrity: we only want to build products that will positively impact our clients and their users. If it’s not possible, we’ll tell you.
3 – Competitive Analysis
There’s no need to reinvent the wheel. This step usually involves looking at what’s already built within your industry. This doesn’t just include direct competitors; indirect competitors can also give important insights on what’s best for your product.
There are two major insights that we uncover here: what’s currently working, and what’s not. What are current features that users love? What problems are people complaining about? By looking at what’s already out there, you can avoid mistakes already made and get inspiration from what does.
The main goal of this step is to ensure you have a product that stands out. We want you to have a unique solution, and competitive analysis makes sure you’re a step above the rest.
Why is Research Important?
We hear it all the time: why is a research phase so important? It does add time and cost up front, so it makes sense that we get some pushback on this step. Here are just a few of the reasons we think a research phase is needed.
Save time and money in the long run
By spending some money and time up front, you save yourself the pain of having to make changes down the road. The longer you wait to make changes, the more time and money it will take to fix it (just like we discussed in our Time vs Cost blog).
If you skip a research phase, you’re going to be waiting until the very last moment to make changes. You won’t get user insights until the app is publicly released, which is when it will be the most difficult to fix things.
De-risk your investment
As you probably know, software development isn’t a small chunk of change. It’s a large investment for any size company to undergo a development project. If you’ve ever needed budget allocation at a company, you know that it can sometimes be difficult to convince an owner or board of directors to give you some money.
Imagine you skip the research phase, and at the end of the project you realize you need to make drastic changes (meaning you’ll need a drastic sum of cash). It will be even harder to ask for more budget if your project isn’t somewhat successful right off the bat. Not to mention how this will negatively affect any budget discussion you’ll have in the future.
Related Article: How the Cost of Change in Development is Affected by Time
Evidence vs Assumptions
Before Slingshot had a research phase, we would build everything based on assumptions. What do our designers and developers think is best? What do the stakeholders think will work? Assumptions could possibly be based on evidence, but more likely than not you’re spending thousands of dollars on opinions of gut-feelings.
By gaining real evidence backed by data, you’ll know that what you’re building is more likely to be successful. Of course, you can never be 100% certain that an app will be successful. But you’re much more likely to build something right when it has a foundation of evidence.
Emotionally-connected design
We take the data from our research phase to map-out an easy-to-use design and a testable prototype. Our designers really enjoy getting a personal feel for the brand and its users. That way, when they move into the design phase, they are creating a more emotionally-connected design. If the process started right at design, the results could be disconnected from what the brand really is in the eyes of stakeholders and users.
What Happens if You Skip Research?
Research is like studying for a test: the more you study, the better your chance is at getting an A. So what would happen if we stayed up all night watching Netflix and didn’t study? Here are some questions to consider if you’re thinking about skipping out on a research phase.
Do you really know your user?
It happens a lot more often than you might think: executives think that they know what their employees or customers want, but they are actually quite off. If you build based just on what stakeholders think is best, you won’t know if it actually works until it’s launched. You can save a lot of heartache, time, and money by gaining insights from the actual users.
Is it already built?
This comes right out of our competitive analysis step: are you sure the product you’re building isn’t already out there? While Slingshot can always make your product stand out, you may want to rethink features and applications if a competitor already has a very similar product that’s already seeing a lot of success.
What if we’re all on a different page?
Every department and person within a company has their own views on what is important and how they determine success. By speaking to each stakeholder about what they’re looking for, we’re able to get everyone on the same page before any code is written. If you wait until the end to see what stakeholders are thinking, your project is much more likely to be deemed a failure.
Is this app what we really need?
Just like we mentioned earlier, there have been times where we’ve stopped a project after the research phase. This has saved those clients so much time and money that they would have spent on a doomed project. Imagine if we had skipped the research phase on those projects: all the time and money would have been spent on a project that could have all been avoided had we done some research.
What if we have to change things after launch?
By missing out on a research phase, you have to wait until an app is live before getting any user insight. Based on our experience, that first iteration or a software product almost always needs major changes to be an ultimate success. By doing research, you can make those changes before writing code and before you go public to your users. But by skipping research, you’ll have to make changes at the most difficult and costly phase of the project.
Conclusion
At Slingshot, we believe all great projects start with a well thought-out research phase. We start by understanding what the stakeholders are thinking. We then get insights from actual users, and see what the competition is doing. While this can take a few weeks and costs some money upfront, you’ll be thankful you took those precautions.
That research phase helps ensure that our apps are built on a foundation of evidence, with a much higher rate of a project being deemed a success. Not to mention that you’ll be saving time and money in the long run.
If you don’t head our warning and skip the research phase, you’re much more likely to have to make changes at the most dangerous point in development. There’s also a chance that your product isn’t actually what users need, and you’ll be throwing away a lot of resources to figure that out if you skip research.
Hopefully this sheds some light why we love research so much! It may seem nerdy, but it’s so worth it. ?
