Running customer discovery calls

Running customer interviews

Success without customer meetings is veeery unlikely. I am going to be blunt here, if you are not running customer discovery calls on a weekly basis, you are doing it wrong. I know it, because I have done that mistake in the past.

Paradoxically, I have tons of experience running discovery calls and usability tests. The thing is, when it is about your product (slash side project, slash next big idea), not someone else’s, a customer discovery call triggers some subconscious fears. “The product isn’t ready”, “I’ll do it after shipping X feature…”

Last time a good friend had to push me towards running some calls. He was 100% right. The amount of usefull insights you can get from a few calls is insane. It is the difference between building something people want and wasting your time and energy. They provide…

1. Insights about what the user really want

2. Feedback on the root of issues not easily visible

3. Remove uncertainty

4. Motivation for you and your team

Users want their problem solved. If they are not being able to do it or get it, the “blame” is only on you…

In that aspect, they can also be brutal. Suspects you might have been avoiding, become blatantly obvious. (team or internal) product discussions you might have had, are suddenly very, very clear. Think in this terms…

it is better to face the problems with your ideas/products now, than build for months to discover after launching. My advice goes like this, go and get conversations with prospects from day 1. Before you start typing or designing anything…

Make a habit out of it, learn how to run them proficiently, become good at it. It will be more useful than any amount of coding or marketing you might do. It is something most people avoid, so you will acquire a unique, very valuable skill in the way. #buildinpublic

Mistakes and challenges, shipping an MVP in 90 days

Mistakes launching a product in less than 90 days

It’s been a bit more than two months since I decided to create something around a problem I care about. I deeply hate meetings. Inefficient meetings are a plague. I am building a solution to help you improve your meetings. What final shape that will have, I am still not sure, it will definitely change along the way, but it is something I want to tackle…. #buildinpublic

Speed is key. I know, it is not as fast as developing and testing in a week as @shl process (I have a couple of ideas I’ll test his process with, but not this one). I had a few domains saved for side projects and that’s the one better fitted for the project…

My goals these past months have been a) validate if there if it is a problem want to have solved (can it get traction?) b) if I can deliver the technical parts, c) can I deliver value by solving the most annoying parts of meetings…

So far it is going great, but I am gonna review some of the mistakes I have made this time. I think it is also important to review your errors. They are not the only ones, but the more painful ones.

Diving fast into developing something you do not know…

Launching the Chrome Calendar Extension. I had zero experience with extensions. I have learned a lot about it during this time. Something that is kinda tricky when developing extensions is there is no easy way to declare environment variables.

Why is that important?

The first time I submitted the extension to the Chrome Store, I forgot to change the (hardcoded) API endpoints! It was approved, but was making the calls to… localhost ?‍♂️. Another important learning there.

Every submission to the Chrome Store goes through a cycle of up to 10 days to be re-approved. Sometimes it takes less time, sometimes more. Insight from all this?

  • Run an exhaustive checklist, making sure that all that could be broken is not broken…
  • Regressive tests are your friends. Not at this stage though, many things will change. But eventually will have a set of regressive tests to run before submitting. Testing chrome extension is a different beast. Will probably write about it at some point…

Mistake number 2, not checking my requirements when picking my stack

Without going into much detail, I found out, when I was already committed with a stack (having developed a substantial part of what I had planned), that some of the things I wanted to be able to do, were…

complicated. NextJs comes with a couple of great advantages, like having an API out of the box. Well, that was not easily deployed on my platform of choice. Also generating dynamic pages had some complexities.

In the end, I was able to overcome those hurdles, but I had at least a couple of stressful days.

Insight?

  • Listing the critical needs of your project. Going through them, and checking they are available in your stack… can save you a lot of headaches.

I think the main lesson is it is okay to make mistakes. Shipping fast, finding insights sooner, make up for the mistakes.

Previously oorei dot com | Comments are disabled