Over the last three months, I’ve been continually fielding prototype suggestions from users. They can be grouped into a few themes:

• General usability & appearance
• Giving more control to how you edit a timer
• Giving more control to how to operate a timer
• Improvements to how you share timers with others
• Enhancements to sound-related features
• Broadening the platform itself, to an embedded or standalone app

Prioritizing

As suggestions are coming in and I need to prioritize my focus, I’m using an impact-to-effort matrix. (I use the number of user votes on a suggestion as a proxy for “impact”). At first this process was done informally – in my head – but now I maintain a spreadsheet. 

Generally, I group similar requests and assign a fibonacci-style effort value to each one. If there are requests that are unclear, I ask for more context and put them into a “researching” state. Of the remaining items, whichever has the highest votes/effort ratio gets worked on next.

Lessons learned

The most important outcome of this whole experiment is that we learn something valuable. So what have I learned this far?

1. As product creators, we often talk about what is important to potential users. Even though these ideas are built on experience, they are often not what users vote for. The reasons for this vary, but one thing is clear: It’s hard for users to imagine what kind of friction or desires they will experience in the product before using it. Once it’s in their hands however, those things are immediately obvious.
2. If you have something useful/valuable, users will make a wide range of suggestions. The vast majority fall into three buckets:
3. ~Making light UI adjustments‍
4. ~Giving more control over existing features
5. ~Building epic features or expanding the platform

The breadth of this feedback resolves a fear I had about this type of work: that users would get stuck in a fixed paradigm of what the product is, and not think outside the box. In reality, if you make something useful, the use cases for the product are more broad than you think, and users will suggest small improvements as well as huge pivots. Notably, the user doesn’t know the difference between them. They will simply tell you what they want.

Engagement

Around 0.1% of MarinaraTimer.com visitors click into the prototype and offer a suggestion. This is a tiny portion, but for the extremely passive funneling methods we’re using, it’s actually not bad. More importantly, it’s a steady throughput. As a solo developer with other responsibilities, I can keep up with the pace well enough.

What if we wanted to scale up? I expect that if we campaigned or incentivized user feedback we would get more suggestions and could eventually scale up to a larger team. It also makes me wonder how we’d generate a feedback pipeline with a prototype that didn’t already have an engaged audience like MarinaraTimer does. I suspect this would be the primary challenge when trying this approach with a brand-new offering.

Another big question is on my mind: Where do we go next with this project? The functional prototype cycle has been proven out well enough, but how does it fit into a larger product-led growth approach? When are we ready to move past the prototype and into building the actual product? What are we missing?

I think we’re missing a monetization model. This has always been true of MarinaraTimer. We briefly experimented with ad-based revenue, and ruminated on a freemium model, but there wasn’t a real strategy behind it. As we continue to learn more about what users want and build it, might there be greater opportunity to offer a better product at a reasonable price? Can we find a way to sustain continuous product improvements ad infinitum?

A group of colleagues and I at ThreeFiveTwo are currently participating in a book club for Product-Led Growth: How to Build a Product That Sells Itself. I’ve only just started reading, but I’m optimistic that it will help me build on this idea of making the product experience central to your work, and building a business model around it. Until then, I’ll be listening to your feedback, improving the prototype,  and thinking deeply about how to keep this experiment going.

🤔