BoolaBooks. Scan. Sell. Save.

customer-feedback

09 Jan 2017

*This post is for anyone looking to build a site or app themselves, and briefly shares our experience in doing so.

When we first started out, we fell for many of the classic blunders that people make when planning software. We were over optimistic in all our estimates and we let our intuition guide our hypotheses around feature planning and prioritization. This proved to be particularly costly given that our team largely works part-time, meaning we have even higher opportunity costs with each decision we make. This post covers one simple example of this for illustration.

When we started out, we were convinced that limiting our marketplace to only students at Yale was critical to our success (Yale was our first campus, but we have expanded since then). We went the most hardcore way we could to achieve this: we required users to sign up directly with their Yale NetId, thinking this would give people that assurance to know they are part of a network. Did we have any data to back this? No. Did we have any customer complaints suggesting a less stringent approach would be any less effective? No. Since that time we have gone with a far easier approach that is several orders of complexity simpler by requiring the specific .edu emails for a given campus. That is super easy to implement, easy to debug, and (based on customer feedback) more than does the job.

The key lesson we picked up here is a classic one: it’s really hard to know what users want and need. Even if they tell you it’s one thing, it might be another! To combat this, the best thing you can do is be as agile as possible. Find the core nugget of value you’re trying to deliver and find the cheapest way to implement and verify that (1) it provides the value you thought it would and (2) how much more functionality you really need. Be agile, be iterative, be customer-driven! You’ll probably save yourself a lot of unnecessary effort while also delivering value to your customers faster.