Navigating the Open Waters of an Early-Stage Product

I’ve been sharing videos and links to the tool we’re building called Flota. At the surface, it’s a new interface for instructors to create agendas. Yet our hope is to improve the experience of creating in-class sessions… So how do we know an agenda builder is the right place to start?

This is the meta of the game called “early-stage product development.” Depending on who you talk to and their school of thought, you’ll get conflicting opinions about when to start building, what to build, how much customer feedback to collect, and when to collect it.

Creating software to sell is a strange mix of personal expression and feedback from users, with each having more weight at different times of the product’s life. Modern startup and product design discourse pits customer feedback and founder intuition in a false dichotomy. The creators are asked to pick a side and stick to it, lest their creation fail.

This black and white thinking has infested the internet. It has infiltrated startup incubators and coaches alike, and the lack of nuance in this divide leads to plenty of mediocre products being put out. In fact, the real skill is knowing what kind of feedback to collect, and when you should collect it. Once you are on that journey, the second most important skill is understanding the difference between ideas that you need to use today, versus bigger picture ideas for the future state of your product or company.

Early product experiments don’t need to be obviously connected to a team’s vision. They are doing their job if they achieve three things:

1. What the team can build quickly to start getting a feel for the future state of the product
2. A sounding board for both the team and any testers to measure what is actually a pain point
3. A business card to demonstrate that the team can build thing and is worth talking to for any parties who are interested

Without an object, thinking and visualizing is often much harder. In many cases founders need to see their flawed creation to know how to make it right. What’s important is that we don’t lose sight of the bigger picture, and start to feel down when things don’t resonate with those who try the early demos.

That’s what’s going to be hard as we develop Flota. For something as monstrous as teaching, with all the differences in teaching styles, organization policies, and access to tools, choosing one ideal place to start was practically impossible. Instead we made a bet, analyzed our skill sets, and made something relatively quickly. We’re now gauging the market to see if people are excited about a solution around time management… and if not, well, the demo still did its job.

If you’re interested in how we learn and teach and impacts of technology on these activities, subscribe to my newsletter!