The Target Techstars Retail Accelerator, for those unfamiliar, was a global retail accelerator that picks a yearly cohort of 10 startups from thousands of applicants.
So my team and I left school to pursue our startup, Pikup (Runerra at the time), full time. This was going to be my first full-time rodeo, not like other side projects that gave me the luxury of going to school and playing for both teams.
So after my freshman year, I left to solve a problem that I believe will change the world. How hard could that be? All I have to do is build what they want.
With 4 years of self-taught UI/UX and Project Management from the era of Edupass (my first attempt at starting a company) I thought as long as I ask users what they want and keep things simple, we’d be off to a great start and would be doubling by Summer.
I was completely wrong.
No one has solved this problem yet so there’s no direct answer.
Users would have solved the problem themselves if they knew how to solve it so don’t ask them how to solve it. Right? Sorta.
If you ask a user how to solve the UI/UX problem you’re being paid to solve, you’ll probably get something pretty vague that sounds like something thats already been done before. They aren’t paid to think about these things. If Henry Ford asked people how to improve their transportation, they would have said make the horses faster.
So when I asked my friends how they would share trips and they told me they should be able to send them to friends like Venmo requests. That solution made sense at first, but the simplicity easily became lost in the complex relationship of marketplace hindrances and solution gamification.
As it turns out, they did want a car, but their solution suggestion will be intrinsically wrong because they didn’t nail the problem.
The problem statement in this case to me looks like:
“I want to get where I’m going faster and easier”
Notice with this approach the space you have to play with solutions. You can see where ‘faster horse’ fits in, but car is now an option with completely unique features.
It’s about knowing the problem, not the solution.
Users know the most important pieces to our puzzle, and we have to surgically remove the important information from general conversations and examples. The most important piece of a product is the problem it solves. If you don’t know why this is important I’d stop to learn more about that, but 80% of what you’re building is a solution, the other 20% is the design and joy. If you don’t know what problem your product solves, you need to stop and determine that first. Not 5 problems. Not 2 problems. 1 problem. Your problem statement needs to be so true Pinocchio could get it tattooed.
People who do and know a certain task generally have the same processes and pain points, and since humans think very similarly, it's safe to say there is 1 correct solution for all of them. Start by gathering your own first-hand research to understand different processes.
Want to improve last-mile delivery? Do your own paper and pencil deliveries. Start having conversations with grocers and friends that use delivery solutions.
Want to make vertical farming more viable? Build a small one and do your own research on the systems it takes to manage a smaller model.
Building better transportation? Explore new ways to make traveling easier and faster than a horse.
Be the most knowledgeable person in the room when it comes to shortcomings and problems with the processes you’re studying. Join forums and make friends because you need to be obsessed with this thing.
As you finalize your problem, begin to piece together your story because that’s what helps you find your starting point for your solution. Why is the story so important?
Context.
If you don’t have context around the job, you lose your ability to relate to important aspects of the problem you need to create the right solution.
Things like where your user is from. Who they are. Age. Where they experience this problem.
It’s like picking out the right birthday gift
When you’re designing any product, you need to think of what is simplest. The less moving parts the better. Simple is the perfect catch, it’s so intuitive the ball goes right in your hands. That’s what the solution needs to feel like, so it’s really important to know what sport your playing.
You don’t need to build an app.
I don’t know who told you that you did, but it is the last thing on the list of solutions, especially when you’re building a Minimum Viable Product. (I might write about that another time) Apps can be useful and cool to say you’ve built. But they’re really not that great. They take up a ton of space and are antiquated. We're at a point where apps are being used like websites. Why can’t we just make websites and our web experiences better? I’ve seen strong progression in the front end department, web interactions continue to look and feel more native, but Google’s front end I wish was less present while using their search platform
So with an understanding of the process and context surrounding the solution, we can use ✨intuition✨ to create a new experience that solves its problem simply and beautifully.
Intuition is what I think separates good and bad work. As much as you have a sense of what the solution is, you also need to have a sense of what feels good. Bad is boring. Bad is overwhelming. Bad is forgettable. Intuition isn’t brainstorming cool features, it's having a sense of what matters in the process and knowing what rules you can break. It’s something that you can develop over time.
When we were developing the process of a run (Going to the store and telling friends ca grab something on the app), We had an assumption to test:
Its too hard to help neighbors while I’m at the store.
We decided to test this the easiest way we knew how. Notify friends as soon as you're going to the store. We built the platform around giving control to the person grabbing the items to reinforce the idea Runerra was more about sharing a favor, but our problem statement was wrong, and so was our platform.
As we tested, learned, and relaunched, our problem statement has become more precise, and we are taking the right strides. The real problem statement is more like:
I don’t know what people want when I’m at the store.
We began focusing on neighborhood lists in April, a solution adjustment that focuses on this more on our user's real problem. Asking people if they need anything puts them in a vulnerable spot, but as we found out through interviews, groups that had group lists felt comfortable offering to grab something when they knew someone needed something.
The important piece of context is that Instacart is a gig, whereas Pikup is a social platform. Now that we understand this, we can continue to connect neighbors together through meaningful interactions.
So in essence, don’t build an app unless you have to. Your solution can be whatever it needs to be and can always develop over time. Whether it's a site connecting neighbors helping each other get groceries, or the world's first mass-produced automobile, don’t build a faster horse.
Thanks for reading my first article! I’m trying something new, please leave a comment and let me know what I should add or write about in the future.
