Comments:"Coworkers as Your First Customers – Your Office As the Ultimate Dev Environment"
After months of development, last week we finally launched our product, Close.io. As many of you know, shipping a product can be an exhausting, exciting and often stressful time as your team races to make sure it doesn’t break! However, it can also be a great time to reflect on everything that’s happened up to that point. In doing so, I realized we did something amazing, not just by shipping a product that people seem to love, but more so how we did it.
What’s amazing was that the core concepts behind my product were developed in the same room as its users, in this case sales people, which doesn’t often happen. I’m not talking about beta users in your hometown; I’m talking about sharing desks (and sometimes headsets) with a sales person as you write code for the product open on their screen.
Startups often build software based on limited understanding of problems, or in the best cases based on their own past experiences, but they still remain disconnected from real users during most of the development process. (There are exceptions if you're creating a developer-facing product like GitHub, but these are relatively rare). And this sucks because, as a developer, it’s too easy to start working on the wrong problems. We went a different way, building our product from scratch as our core users actually used it. Here is a look inside our unique development environment and why you need to try our method too.
Our Dev Environment – Sharing Desks With Our Users
The biggest single way to take good software and make it great is to have the experience of watching coworkers (with no training) try to use it. Other good companies try to do it with focus groups, friends or even going up to people at Philz Coffee, but the ability to do this every day in a real work environment is very insightful. In our case, we had Elastic’s sales team use Close.io to make sales and manage the entire sales process for each of their clients. This gave my development team direct feedback on real, live sales campaigns for dozens of clients, in a variety of industries. Both seeing new users try it (when we hire someone new or introduce Close.io to a client), as well as seeing how existing users try out a new feature or redesign, is really helpful. The best part is that this can be done anytime just by walking over to a coworker and looking over their shoulder.
This feedback loop went several steps further over the course of the product development. Sharing space (sometimes even desks) with sales people, having lunch everyday, happy hour and even trips to Vegas developed a bond between the engineering and sales team that would have been impossible to create had it not been for us working so closely together. We even went so far as giving my engineering team headsets and having us make cold calls to get a better understanding of sales. Additionally, if a sales person had their heads in their hands, frustrated with a sales call or the platform itself, our process allowed an engineer to walk over to the sales person, discuss the root of the problem, and walk away leaving the sales person with full confidence that we’d develop a solution to those frustrations.
This process helped us simplify workflows, see reactions, and identify pain points in the software better than anything else. On numerous occasions, we thought a feature was simple to use, but realized after watching users that it could be much better. There’s really no substitute for watching real life users and I can't think of a better way to have developed Close.io than side-by-side by our sales team – our first customers.
Challenges & Risks
There are, however, challenges working in this way. Users, in this case our Elastic sales team, would occasional walk over, interrupt development workflow and ask us about bug fixes, timelines for new features, etc. We can’t really blame them though - if the person I needed to speak with were sitting across the couch, I would probably speak with them face-to-face too.
Additionally, one risk of this development model is focusing too much on a single group or type of users all the time. In early versions of the software, we did a really great job making those people, our sales team, super happy but eventually realized we were solving problems a little too narrowly. It wasn't as bad as it could have been because Elastic didn't just do one type of sales, they did sales processes that were completely different per client. However, there was definitely value in getting external people with completely different types of needs to start using the product and hear their feedback.
Our Gains
By working side-by-side with “real users,” my engineering team was not able to simplify workflows; it also gave us a lot more access to direct ideas and “you know what would be awesome…” conversations. Some of those are things we (developers) would have never thought of ourselves, but turned out to be a great feature. Other times their exact idea didn't seem great from a product perspective, but it sparked something even better.
I can also say that before this effort, I couldn’t call many sales people friends or even colleagues. Engineers tend to know other engineers for good reason; we’re all working on similar things in similar ways. However, working and spending quality time with our users allowed me to form connections with people to whom I’m rarely exposed, expanding my understanding of technology needs and ultimately improving what’s important – my product.
Depending on your market, it may be difficult to replicate this process. I’d imagine it near impossible to set up shop in a doctors office to tweak your EMR, or a law office for a new eDiscovery tool. But if you find a way to build your product “in the same room” as your users, watch them carefully and keep the communications channels open (even if sometimes distracting), you’ll be amazed how your product evolves. I’m eager to hear if any other companies have tried this method of development and your experiences along the way.