{"componentChunkName":"component---src-layouts-blog-post-js","path":"/insights/2019/06/30/the-importance-of-testing-your-riskiest-assumptions-as-earlier-as-possible","webpackCompilationHash":"e9b84744a928659eb31b","result":{"data":{"markdownRemark":{"html":"

Last year, when I was mentoring at a Startup Weekend, there was this team that wanted to create a service that would deploy drivers on-demand for people who would go out with their car but drank a little too much to drive back home — think of it as some sort of Valet Parking, but instead of parking your car, they would drive you home (with your car) — don’t judge the idea, this isn’t the point of the article, bear with me.

\n

When I was thinking about different ways to validate their ideas before writing a single line of code, I suggested them to go out that night to a couple of nightclubs and approach drunk drivers as much as they could to offer them a ride home.

\n

Of course, someone said: no way! How would someone give me his car if he doesn’t know me? Bingo! That, right there, is the riskiest assumption for this particular team. There’s no point at all in building a robust product if there’s a potential risk of being mistrusted by your target market. You have to be able to identify and mitigate those risks before pouring all your money on this product.

\n

For this particular product, going out there and asking wether someone would use this service is rather enough; in a simple questionnaire format, someone could tell you she would definitely use it, but in real practice she just wouldn’t trust you to drive her home. This is what I call a false positive in customer development. That’s why I encouraged them to perform this test by offering an actual service, instead of just asking the usual questions.

\n

Before fulfilling the team’s desire to build an app, they had some pressing issues that needed to be addressed beforehand, like: 1) how can they be trusted by the target market? 2) would anyone use a service like this at all? 3) what are the legal constraints for this service and how can they assure the customer that she’s fully covered if something bad happens?

\n

Now, just as they where hesitant to go ahead and perform this test, you might be thinking, it’s kind of crazy to just go out there and tell someone that we are a valet-to-home service company without actually having a real company that backs your claims. I can’t deny that having everything in order — legal, tech, personnel, etc.. — would make it easier for gaining trust, however, getting all that backup in place is super expensive and, at this very moment, you don’t even know if people would even use this service at all.

\n

So, next time you are working on a new product, don’t forget to test your riskiest assumptions early and often.

\n

Don’t fall out in the false positives trap.

","frontmatter":{"title":"The importance of testing your riskiest assumptions as earlier as possible","date":"June 30, 2019","author":"Alfredo Juarez","featured":true,"avatar":"https://cdn-images-1.medium.com/fit/c/100/100/1*OQgaBPUritgTf9TvdopTtQ.jpeg","category":["Business","Product","Design","Startups"],"tags":["Product Design","User Research","Market Development","Business Development"],"image":"https://cdn-images-1.medium.com/max/2600/1*5tVbCZQ4cBYNGThc0470CQ.jpeg"}}},"pageContext":{"isCreatedByStatefulCreatePages":false,"slug":"/insights/2019/06/30/the-importance-of-testing-your-riskiest-assumptions-as-earlier-as-possible","prev":{"node":{"fields":{"slug":"/insights/2019/07/03/software-development-from-a-business-standpoint"},"frontmatter":{"title":"Software Development from a Business Standpoint","date":"2019-07-03T00:00:00.000Z","author":"Alfredo Juarez","avatar":"https://cdn-images-1.medium.com/fit/c/100/100/1*OQgaBPUritgTf9TvdopTtQ.jpeg","category":["Business","Product","Design","Startups"],"featured":true,"image":"https://cdn-images-1.medium.com/max/2600/1*f5D1TCdEqjeuElPkPY2-wQ.jpeg"},"html":"

There’s a big chain of retail stores with presence across many Latin American countries that has this protocol of having someone greeting you whenever you enter or exit the store.

\n

Every time you enter the store, you can either smile back or just pass her by — I hope you do the former option, but this isn’t the point. What I am trying to say, is that, this simple gesture has a real reason behind and is, indeed, a business reason.

\n

In Mexico, there is a common saying that, everyone owes them money and they are well known for their well-defined practices for getting paid. So, everyone owes them money and everyone hates their approach to collect their debt, so basically there’s a love/hate relationship between the company and its customers. So, by having someone greeting you with a big smile, they are lowering your defenses before you even enter the store.

\n

As developers, we love to write tons of lines of codes. We stumbled upon a problem, analyze the situation and write an algorithm that potentially solves such given problem. The problem with this approach is that we never tend to see the situation from a business standpoint.

\n

This is something I learnt a while ago. I thought I was taking our customers into consideration, but the truth is, I was more focused — and more excited — on how I was building the product. Am I using the best tools? Am I designing the best UI? Am I creating the best user experience?

\n

Focusing on how our product impacts the business instead of just focusing on how we are great developers is more important for the product than being able to build the product fast with the best technology.

\n

Once I understood that what I build must have an impact in an aspect of the business I am working on, I became a better developer, because now, I build products that do move the needle and this is something very valuable for our customers at Juvasoft.

\n

So, fellow programmer, the next time you work on a product, think about how every feature moves the needle in terms of business value. Think about the person greeting you at the store and why that is happening in the first place. Focus on value added, not lines of code written.

\n

You can thank me later.

"}},"next":{"node":{"fields":{"slug":"/insights/2019/06/15/a-common-mistake-done-by-startups-when-choosing-features"},"frontmatter":{"title":"A common mistake done by startups when choosing features","date":"2019-06-15T00:00:00.000Z","author":"Alfredo Juarez","avatar":"https://cdn-images-1.medium.com/fit/c/100/100/1*OQgaBPUritgTf9TvdopTtQ.jpeg","category":["Business","Product","Design","Startups"],"featured":true,"image":"https://cdn-images-1.medium.com/max/1200/1*dEPKStsS2pMLpvNbBnm_Uw.png"},"html":"

Don’t let your roadmap be defined by a soon-to-be customer

\n

\"Product One common mistake I’ve been seeing on early stage startups is when they let customers drive product development. But don’t get me wrong, what I mean is that they tend to develop a feature or set of features just to be able to close one client.

\n

This is a mistake I also made earlier in my career. When I was running Cloudadmin, I had a clear, well-defined product roadmap, however, every now and then, I used to fell for the trap of building a feature in order to close a new customer. I realized this when I came to a point when the Product was big enough to cater to many types of customers but not great enough to have a perfect fit to at least one vertical. (If you know about sales for startups, you’ll know that you need to start with one niche and move forward to neighboring niches).

\n

“Every feature needs to answer a big why, and just because a customer said it so isn’t good enough.” Tweet this (Can be edited)\nI have written before about finding a problem before you start working on a specific Product — Just as you would talk to many people to find a problem, you have to do the same to define the feature set for the first iteration and continue to do so to build the entire roadmap.

\n

Defining the Product Roadmap is crucial to a startup success. Every single feature needs to answer a big why, and just because one customer asked it for isn’t good enough. Even though Product Managers find needs by talking to and observing on customers, we need to be able to identify patterns; when it is a common need and when it is just one customer’s whim. Remember, customer’s are not your Product Managers.

"}}}}}