Building Products Users Love: The Power of Early Feedback and Product Discovery

Think back to the evolution of race timing. We've seen it move from manual stopwatches to sophisticated digital tracking, all in the pursuit of accuracy, efficiency, and a better experience for runners and race organizers alike. This progress wasn't born in a vacuum; it was driven by understanding the needs and challenges of the people using these tools and a strong desire to make improvements, no matter how small. Similarly, when building any product the key to creating something truly valuable lies in deeply understanding your potential users.

‍

The stark reality is most companies don’t follow this best practice. Product decisions are often made based on gut feelings or intuition. Decisions are made based on what a business leader or a product manager thinks is best without consulting users. Sometimes new products are rushed to market based on a founder's idea without seeking input from potential ideal customers. Maybe in some cases high level market feedback is gathered, but as the product is developed or iterated upon it is not put back in front of customers for more feedback. Oftentimes the product roadmap becomes hijacked by purely revenue driven initiatives, or, even worse, a product company slowly finds itself becoming a services company because they are pivoting to each unique customer ask versus taking the time to look for patterns, trends, and where there’s common value across multiple users. 

‍

Unfortunately, I’ve witnessed all of these things take place first hand at multiple companies and I’ve always said to myself “if I have the opportunity to build a company one day I am going to put the customer first”. To me you can’t take a new product to market, build a company, or grow a business without continuously getting feedback from your customers.

‍

That customer first ethos is a big part of of Product Leader, Marty Cagan’s and the Silicon Valley Product Group’s books: Inspired, Empowered, and Transformed. Inspired’s tag line is “How to create tech products customers love” and that has stuck with me since the first time I read it.

‍

This is why we’ve placed such an importance on the product discovery process at RaceOS. Before we even thought about writing lines of code or final designs, we were engaging in thorough product discovery sessions and meeting with timers and race directors to get feedback on the concept. That feedback helped evolve our ideas and became our first wireframes. Did we dive right into building then? Nope, we sure didn’t. We went right back to our most valuable asset: timers and race directors. We got more feedback and that feedback informed what we’d build for our first prototype. 

‍

We were really excited about getting that first prototype built in early Q1 and then spent the end of Q1 through now having dozens upon dozens of conversations with race directors and timers to get feedback on the prototype. 

‍

Getting feedback over and over from potential users is paramount. It's the foundational step that can mean the difference between a product that solves real problems and one that gathers dust on a shelf. We don’t want to be in the business of building dust catchers, we want to be in the business of building great endurance event software that makes and impact on the industry and on people’s lives.

‍

Why Talk to Your Users Before You Build?

Imagine pouring countless hours and resources into developing a race timing system only to find out that it doesn't do the trick for someone who you may have considered a potential power user, or that the reporting features aren't user-friendly for busy race directors. This scenario, unfortunately, isn't uncommon when product development happens in isolation, and even more unfortunately that happens a lot more than you might think.

‍

Meeting with potential users – race directors of varying sizes, experienced timers, and even passionate runners – has provided us with invaluable insights that you simply can't glean from behind a desk. 

Over the past couple months we’ve spent countless hours gathering feedback and here’s what those conversations have helped us to do:

• 🤕 Identify real pain points: What were the biggest headaches they faced with current solutions or manual processes? Were they struggling with data management, volunteer coordination, cost, or runner engagement? One thing we heard resoundingly from everyone we spoke to, whether Race Director or Timer, was that the pain of managing manual processes and disintegrated systems was very real for them. Understanding these pain points ensures RaceOS will address actual needs.
• 🤔 Validate assumptions: We might think we have a brilliant idea, but did it resonate with everyone or just a few people? For example, we’ve gotten unanimous feedback that being able to automatically detect course deviations is of huge value. We assumed that and it was great to get that validation. However, we also assumed providing a simple flag was sufficient for surfacing those course anomalies. Well, we learned it wasn’t. Users want to be able to triage those independent of all of the results and then take action on those flagged results. User interviews helped us test our assumptions and ensure we are building something people actually wanted and would use.
• 🕵️‍♀️ Uncover hidden needs: Sometimes, users don't even know they have a need until you start exploring their workflows and challenges. Product discovery sessions revealed these latent needs, giving us a unique opportunity to innovate. There’s one feature in particular that got resounding positive feedback that doesn’t fit into the timer or race directors workflow today and is a huge value add. We know we have to double down here after further uncovering and understanding this need.
• ✅ Prioritize features effectively: With limited resources, we can’t build everything and we can’t build it all at once. Our aim is to get a high reliable, extremely accurate, scalable timing technology solution in the market. The first version will be minimally viable though and that means user feedback is paramount to helping ensure we’re focused on the right things for the MVP. Feedback we’ve gotten throughout customer discovery sessions helped us solidify our blueprint for the MVP and build a future roadmap that we can iterate on to continuously add value for future customers. It also helps ensure we are focused on the right customers. We can’t be all things to everyone at all times, especially right out of the gate, so ensuring we have a clear understanding of our ideal customer profile and that we’re building to their needs is critical.
• ❤️Build products people love: When users felt heard and saw their feedback incorporated into a product, they developed a sense of ownership and excitement over what we were doing. It was beyond rewarding to see people light up, offer to help, offer to test, and be willing to be an ingredient in our recipe for success. That tells us we’re doing the right things that will build advocates when we officially launch the product. 

‍

Incorporating Feedback: Turning Insights into Action

So, where do we go from here? Gathering feedback is only half the battle. The real magic happens when we actively incorporate these insights into our product development process. For us, that means:

• 🔄 Iterating on our initial concepts: User feedback opened our eyes to what we were doing right, but it also revealed things we need to add, change, or think about differently. The feature we mentioned above about course deviation detection is a great example of this. We went into this process with an open mind and an openness to adapting our vision and will now iterate based on this feedback.
• 🗺️ New blueprints: With new clarity and vision, we're updating our blueprints. All the way back to wireframes, user stories, and requirements based on what we've learned. This will become our map for building the MVP.
• ✅ Prioritizing features based on user needs: Next we'll focus on building the features that users have identified as most critical and prioritizing those for the MVP. You can't do timing without scoring and awards, right? We'll make sure we're focusing on the core engine of the platform first and then the core user workflows from there.
• ✨ Refining the user experience: We learned a lot about how users might engage with RaceOS and how they'll use that and that means we have to update some of the workflows, which we'll do. We'll have to pay close attention to how users interact with future iterations or the prototype and continue to make adjustments to ensure a smooth and intuitive experience.
• 🧪 Test: We are committed to putting a highly accurate, highly reliable, novel timing technology solution in the market. That will require rigorous testing. First, internal testing. Then testing with beta users.

‍

The Takeaway: Listen First, Build Second

In the journey of building a successful product, especially in the dynamic world of race management technology, the voice of our potential users is our most valuable asset. By prioritizing product discovery and actively engaging with the running community prior to launch, we can gather crucial feedback, build a product that truly solves your problems, and ultimately create something you will love. The feedback process is continuous. It doesn't just stop after this first round of prototype feedback. As we iterate and build we will stay connected with our design partners and get feedback on what we're implementing to make sure we're staying the course and still building something that will be embraced by the running community.

‍

Stay Tuned!

Building a product race directors and timers love requires your engagement, which we’re grateful for. If we haven’t already talked, please contact us so we can get your feedback and incorporate that into our product development process. If we have talked and you want an update in between posts, reach out! Otherwise, stay tuned here for more updates on our progress and for insights on the industry in our regular recurring blog series. Our next article in the series will delve into how to choose the right timing system for your event. Subscribe to our blog to be notified when it's published and gain even more valuable insights.

‍