The concept for RecBob was born at a Startup Weekend event. On a Friday night in September, five people grouped around a basic problem best expressed in the following statement:
“As a team captain, I’m never sure who’s in and who’s out for the next game. Do they even know we’ve got a game tomorrow?”
Between Friday night and Sunday afternoon, we performed customer and market research to validate the problem and market, leading to a basic business model. Simultaneously, we created a technical solution for the problem and built a functional prototype, with forward-looking mockups and branding.
After presenting, we received positive feedback and were excited about what we had created. We were so excited that ten weeks later, four of the original five dedicated ourselves full time and founded the company.
The primary roles on our team were: CEO, engineer, product designer, and marketing/outreach. With the exception of the engineer, we frequently contributed to areas other than our official wheelhouse. The CEO, who has an engineering background, started out coding next to our main engineer–until business needs and fundraising demands quickly pulled him away from the keyboard. I created marketing materials and sometimes coded on the front end.
The only member who “stayed in his lane” was the lead engineer. For such a technically pivotal role, there really wasn’t any other option, even if he had wanted to branch out. We all played a role in business and operations decisions, though. So even the engineer had to wear different hats on occasion.
…as if there is any other option for a startup to survive. We used Trello to track sprints and stories before it was cool. Since we were all pooled in the same office, communication and collaboration happened pretty naturally. Answers to questions were literally a tap on the shoulder away.
My favorite part about our office was the markerboard walls. I used them every day to sketch out concepts and get instant feedback. I would leave some up for people to leave comments whenever they thought of something. The other founders kept notes on business needs, technical requirements, and marketing campaigns on the walls too. It was an effective and rewarding way to stay abreast of everyone’s projects, and to have immediate visibility on how they might impact yours. Because of the development environment we fostered, the rate of improvement often felt more like a constant, rather than stages or fits and starts.
We started with a pretty simple problem statement and solution. However, the path to an effective product quickly became a labyrinthine morass of user types, devices, and work flows that needed to be taken into account if we were to be successful.
Team captains, players, and subs each had different needs and pain points. Even shared needs tended to be felt or seen from different perspectives, which meant unique solutions were needed. Mental and physical environments mattered, too. Are you checking your roster at the bar? Are you confirming attendance on your way to the gym? Are you setting up your team’s schedule at the start of the season? Each of these scenarios is likely to mean a different device in a unique environment, with a host of different goals and mindsets.
The growing complexity led to many questions:
~ Which problems do we solve? And how?
~ How do our solutions relate to each other? Do they create straight paths for our users to follow, or something more like a random walk?
~ Does Feature X fit within our current architecture, or are we creating an ungainly mess?
Information architecture, user flows, personas, and other UX artifacts (paired with data models, feedback from engineering, etc.) assisted our search for answers.
To be perfectly honest, the initial answer would have been: “That’s what our team knew to build.” At a later fork in the road, however, we asked ourselves if we should instead build a native app for iOS or Android. Limited resources meant we could only pursue one option. Questions arose, such as:
~ What are the critical needs for our users?
~ Which users are most important to our business?
~ What are the costs to pursue each solution?
Long story short, team captains were our most important user group, and they were likely to need access to a full-featured website at home *AND* access on their phone at the game. The features accessed at home were the differentiator for the captain, and most use cases at the game required an active network connection. This left one-touch accessibility as the most salient benefit of a native app. While not unimportant, it was not enough to outweigh the benefits and flexibility of a web application.
In discussions with early adopters, we discovered a critical weakness. If any player on a team wasn’t using RecBob, the app could be worthless (depending on who the holdout was). So one person’s inability to join the platform could mean losing out on the entire team of users!
I could imagine every team in America with one smartphone-less luddite or a guy weary of signing up for new services. Hypothetically, this could mean RecBob was effectively useless for… everyone.
Frantic problem-solving led us to the idea of redshirting users. A player could choose to join a RecBob team without signing up for RecBob. On the backend, we created a hidden placeholder profile to allow for basic team functionality. The redshirted player could then receive game reminders, rsvp for games, and otherwise normally participate through their chosen method of communication–all without ever directly interfacing with RecBob.
Any number of variables can get in the way of ideal user research. The target users or their lifestyle may be inaccessible to you. Sometimes the nature or novelty of the product limits what you can learn from “real life” interactions that don’t yet exist. Workarounds always exist, but one of the nice things about working on RecBob was the fact that we didn’t really have any of those research restrictions.
We literally walked in our users’ shoes, from start to finish. In addition to talking with our teammates, opponents, venue owners, and anyone else involved in rec sports, we were able to experience all of the highs and lows ourselves.
I can tell you, there is nothing that feels better than when your own product comes through for you and delivers that moment of delight. There’s also nothing that stings more than that product failing you, as you instinctively curse the stupid, short-sighted creator of the app.
Experiential data and online metrics. Qualitative and quantitative measurements. If you’re not getting all of the above, you’re probably missing something.
I needed to talk with influential users who lived two time zones away, so I conducted remote user interviews. I needed to know, in the aggregate, how people were using RecBob, so I laid out the actions and pages to keep an eagle eye on the metrics. The best way to get high-volume feedback on designs and marketing templates is to run A/B tests and generate heatmaps based on real user actions.
We were getting a lot done running on all cylinders. But not enough. We needed to bring in help.
Our biggest need was engineering. To find the right fit, we went long-distance. We managed a great working relationship with our guy, holding standups every morning and staying in touch throughout the day. We utilized the latest tech to facilitate remote collaboration.
Over time, we grew to have close working relationships with many others. Some were temporary interns. Others were contractors. All were quality people who fit our culture. We actively built and maintained the group vision. This meant a lot of listening. And it meant playing hard; not just working hard.
We experienced 18 months of trials, tribulations, and successes. Then we struck startup gold. We were accepted to a TechStars accelerator (partnered with Nike). To turn a long story very short, we learned a few things. The most important discovery was how the big dogs looked at our business. Sure, we had created a product to solve problems for people. Yes, there was a market for it. But…
The refrain we heard from most of the mentors was that, first and foremost, our market was too small. That alone was a disqualifier for most investors. The fact that the market was crowded just made it an easier “No.” VCs don’t look for base hits. Every investment must have at least the possibility of a grand slam. We were effectively given the following choice:
Do we continue with our current business model and build a “lifestyle business” (a dirty word in VC land) on our own, or do we swing for the VC fences?
In that environment — surrounded by all of the inspiration and the resources available to us — striving for anything less than a home run felt worse than merely missing an opportunity. It felt like neglecting a duty or an honor. Along with the rest of my team, I knew that I could not have chosen a base hit without spending the rest of my life asking questions. “What if…?”
To make another long story short, we ended up pivoting. A lot. Eventually, we landed on what became NextStep.io. That story will be coming next month.