Yogi Product Development

by Justin Hakuta 

For my final project I worked on developing a prototype for an online yoga community I’m launching.  I also focused on customer acquisition and landing page optimization.

Here are some lessons I learned along the way:

Developing a prototype

See the future, act in the present.  When conceptualizing and designing a prototype, it’s easy to get lost in the grand vision, the mature steady state mode with all the bells and whistles and network effects-based value and functionality established. The danger of this tendency is you can end up designing something that is way beyond a minimum viable product where suddenly everything seems essential, despite having designed a bloated product with layers of functionality that connect to untested hypotheses. This can lead to a drawn out, expensive development cycle that results in a product that hasn’t been vetted by the customer.

I would recommend first knowing what the grand vision is for your product at a high level to satisfy your ambition, then peeling away the complex layers of the product until you arrive at the most basic version, or what should be built today, based on major hypotheses, speed to market and essential value proposition. Easier said than done, but with this work complete you then have the long term vision in place and the short term MVP planned and ready to build and can proceed to test critical hypotheses. To date my team has launched a live beta site (www.avacara.com) and is currently working with customers to optimize our value proposition.  

Managing across cultures

I have a team of four engineers in India. Note that they are not a third party firm- they work for my startup full time. My co-founder in the U.S. speaks their local dialect and additionally another senior member of the team based in the U.S. is from India. Having the language and cultural factors in place as well as the technical skills is critical to effectively managing an offsite international team. The fact that both my co-founder and another senior member of the team stay up late into the night to work with our India team doesn’t hurt either. Additionally, because they are on staff and not working on a project basis, we are able to train them over time and develop a strong relationship which has proven critical when pushing them to meet deadlines (we sent them bonuses when several of them recently got married). We were able to plug the team into an existing office infrastructure including an onsite manager and therefore getting them up and running was a relatively quick process. Finally, one of our U.S.-based team members recently had a chance to visit the India team and in doing so, was able to identify a host of communication gaps and process improvements that have since helped greatly increase productivity. Even still we occasionally face challenges that hamper productivity (e.g. electricity outages, cultural communication barriers, technology issues). Overall, working with our India team has been a boon to our development capacity; however, it is far from a no brainer.

What about sites like Elance or Guru? Expect to spend about $3000, wait double the planned project time line, get 60-70% of the MVP you actually want depending on your technical skills and cultural awareness plus a lot of miscommunication and frustration. Outsourcing can work, but unless you have the majority of the factors listed above accounted for, I would say it’s more risky and far from a sure shot and at worst can lead to an expensive, half-baked product that isn’t worth your time.

Developing an opinion on development

If you have a non-technical background and are working with a development team to build a product, make sure you understand the difference between elegant development (modular structure, easy to change/refine) vs. hacking (quick & dirty coding, interconnected, hard to change) because the development decisions you make early on will determine your future options in relation to factors like scalability and ability to iterate. The aforementioned considerations are fairly rudimentary and go much deeper, but even knowing this basic perspective provides increased granularity in regards to building considerations and the basis for a common understanding of the development process with your engineering team. Oftentimes just handing over a list of site requirements to a develop is not enough to ensure the final product you want, as different developers can deliver the same end-product on the surface, but have entirely different under-the-hood implementation which can drastically effect your options for iteration down the road.  Understanding their development philosophy is one way to gain a deeper understanding of their skills and habits and what the end product will look like from a code level.

Keep in mind that hacking a solution can be very easy for developers to do, especially when working to meet deadlines and unless you’ve discussed this approach ahead of time, you won’t know what’s happening or what to expect in terms of output beyond the end user level which is important but also only one perspective.  Establishing guidelines for when it’s ok to hack and when it’s not, for example because you’ve identified an area that is likely to be built upon, changed or is a vital product feature, allows for your team to operate using a common development philosophy that is aligned and informed by your best interests both in terms of speed to market and integrity of the product.

Building a movement

Which perspective do you find more meaningful?  Selling a wrench vs. selling a tool that allows you to fix your home and take care of your family.  Creating a larger context for your product that connects its value to a fundamental personal need is as important as building a product or service that addresses a substantial customer pain point.  I found this perspective surprisingly easy to lose sight of when focused on building the product and designing functionality.

Initially, I tried promoting mainly the function of my product to customers and received mediocre engagement results.  But then I identified the movement that my product connects to.  In a nutshell I am working to make yoga accessible to everyone.  This connects to specific functionality for students, teachers and other stakeholders within the yoga industry, but ultimately it is this high level message and value of making yoga accessible that I have found initial success with in terms of engaging customers in something that they care about that includes but also goes beyond them.  Further, in creating a manifesto that synthesizes my argument for the movement’s relevance, I equip my customers with the ideas necessary to get excited and help spread the word.

Know what your movement is and also how it relates to your specific customer types.  Also know your role in the movement you are connecting to.  Are you a good candidate to be a face for the movement?  Or is one of your customers better suited?  To date I have worked with my movement to help recruit a core customer group that I am in touch with for product feedback, insights and encouragement.  Building my movement will play a fundamental role in both product refinement and community mobilization.  What is your movement?