My First Failed Product

This blog is going away soon! :( Check out my new site where you can read the latest and subscribe for updates!

A few weeks ago, I wrote about my first successful product. Now it’s time to talk about the product that came before that - the one that failed!

Note: I worked with a bunch of awesome people on this product, and this article isn’t intended as a reflection on any of those folks - just things I’ve learned about my own process, and how I should approach building products.

The failed product came before the successful one (as is usually the case). It also came afterward. I attempted to use lessons from the successful product to build a better V2, using better engineering and UI/UX. Those were good lessons to apply, but they were the wrong lessons.

Scope creep is a real thing

It started as a simple data tool that, on the surface, wasn’t even intended to have a UI. But as I started demoing progress, the suggestions came of “oh, this would be really cool!”, and before you know it, I had built a tool that had a UI, and was integrated with one of our vendors in every way possible.

In a way, this is using Agile methodologies. But it still doesn’t generate the same value as Agile. We ended up more focused on incorporating every possible feature, rather than solving the day-to-day problems the team was thinking about.

For my successful product, we had one goal: take the process that was manual, performed by a data team, and make it self-service. We added peripherals, but those came later.

The pain wasn’t big enough to force a change

Looking back, I believe this is the main reason this product failed. The people it was intended to serve had a process, and even though it was awkward, it worked. They had confidence in that process. They understood that the process had nuance, and didn’t trust that my product carried the same nuances.

In contrast, the team who used the successful product was still defining their process, and by working with them from the beginning, I not only had a hand in shaping that process, but also understood much of the nuance.

What I would have done differently

SO MANY THINGS!

• Shadowed team members on several deliverables to learn the ins-and-outs of their process
• Define the scope of a single problem to solve
• Use a service or concierge model to test solutions
• Then work on incorporating in to our web app

To a lot of engineers and PMs, this is obvious. But, sometimes, you have to make a mistake to really know that it’s a mistake.

Feel free to connect with me!

• https://www.linkedin.com/in/jeremiah-coleman-product
• https://twitter.com/nerds_s
• jeremiah.coleman@daasnerds.com
• https://github.com/colemanja91