What’s something that
- You can implement in a couple of weeks, and
- Can speed up getting to Product Market Fit and beyond?
This question should be high on every PM and entrepreneur’s list.
The most punishing bottleneck for startups, especially those at early stage, is generating enough user feedback to guide their product. Pre-PMF products don’t have tons of users to run A/B testing or surveys. Conducting user interviews is tough as well: user time is precious, so it’s a lot of work to get them to agree to talk to you in the first place. It’s another challenge for the user to recollect and share candidly how they experienced your product.
To do that consistently and thoroughly, with every feature launch or new iteration is one of the most draining operations in product development. When done well, though, continuous discovery can make the difference between the best and the worst products.
So is there a solution to efficient and inexpensive product feedback?
There is: use your own team’s experiences as the first-order approximation of what users will feel. Known as “dogfooding” around Silicon Valley and beyond, making sure everyone at your company regularly uses the product is a popular product development tactic. The employees at your company are of course unlikely to be a perfect representation of your user base, so anything you get will be biased. But you can learn invaluable things at a fraction of the effort of continual user research and testing – if you put effort into doing it right.
At Facebook, it wasn’t enough for employees to be using the social network to catch up with our friends. Dogfooding happened at several levels. Initially our internal communication was only done in Facebook Groups, later in Workplace (Facebook’s for-work product). We used Messenger for DM-ing (not Slack).
But it went beyond that. After years of Facebook primarily giving employees iPhones, Androids were on the rise, and a campaign began to encourage people to pick up Android devices. PMs often carried two devices: a brand new iPhone, and a 4-year old, cheap Android – to force themselves to face the experience of the “civilian” Facebook user.
That still wasn’t enough. Even on an old Android device, as long as you live in a modern city you’ll be used to excellent connectivity and plenty of bandwidth. So Facebook engineers specifically built throttling settings that would replicate the random packet loss, low bandwidth and lagging connection that, say, a user in rural India would have. On 3G Tuesdays, this would be the default set for all devices in the company. It was a pain! Having messages stuck and uploads fail during your workday was a net productivity sacrifice. But this way, everyone could empathize with and prioritize work for the users who live in that reality every day.
Of course, this feels natural for a company like Facebook working on a communication product that’s used daily. That extends naturally to a lot of products – Monday.com is obviously using Monday.com to manage tasks, Google uses Google Docs, and Github is on Github. The startup I worked at prior to Facebook would even email employees (and their manager) if they hadn’t had the app running on their phones. But what happens if you wouldn’t naturally use your own product?
Well, Cord used to be in that exact situation. We develop an API that other companies implement in their product to add collaboration–commenting, chat and so on. We have two users: developers who have adopted Cord’s SDK for their product, and their own end-users. So we have two experiences to “dogfood”: the developer experience of building a real app with Cord, and the end-user’s experience of the collaboration interface.
Early dog(fooding) days at Cord
We thought we were dogfooding as much as we reasonably could. We used Cord in our clients’ products: we ran surveys in Typeform, used Monday’s WorkCanvas and managed our business intelligence dashboard in Preset. Those early-adopters gave us some critical experience of what it was like to be an end-user interacting with Cord in the real world. We had a Chrome extension that we used to leave comments inside of cord.com when working on our website. We constantly built with our SDK to test things in our “testbed” – a little local demo space that gave you god-mode-like power to play with the newest components. We even had a “Cordathon” to build new apps with the Cord SDK and document all the issues that came up during the hack.
All of these were great – but not nearly enough. They were barely, and superficially, touching the surface of the SDK. We were just dipping our toes into the user experience. The testbed was a short approximation of a developer trying to create a good, coherent, engaging and native experience with the SDK. It was a workbench, a place where you styled your components in Comic Sans MS and never tried to reproduce a user experience that was actually good. We were using it mostly to debug features and could never notice what the pains of a real developer trying this out in an entirely new project would be. The hackathon was limited, sporadic, and not everyone managed to work well with the constraints to create more than a nice-looking demo - a far cry from a real app.
When it came to communication tools, we couldn’t, in the early days, find a Cord-enabled product that would fit naturally as a daily part of our lives, as a very small team of engineers. We would find ourselves learning about bugs only after they hit production, in client’s apps or from their users, rather than catching them ourselves. This is a situation we never wanted to find ourselves in.
We needed something bolder. We needed to really become our own lab rats. We realized that putting ourselves at the cutting edge of the Cord implementation experience would mean actively making life difficult for our team.
No pain, no gain
The announcement was super controversial. We were going to stop developing new features for clients in order to build an internal tool. One which we already had a solution for. We were going to replace Slack.
Building the tool as an experiment was one thing – most engineers didn’t bat an eye (though product, sales and marketing sure weren’t thrilled). But we also announced that none of us could use Slack anymore. We’d only use Clack – a Slack clone built entirely on Cord. Suffice to say that this suggestion was not at all accepted with warmth. Even I said “Well, Cord isn’t really meant as a Slack replacement”, dreading what I’d lose from the app I spent half my day in, that was built by hundreds of engineers for over a decade.
The idea of dogfooding is far from a new concept. Nor is it exclusive to the world of product development. The Doctor Barry Marshall gave himself peptic ulcers to prove the condition was borne by infectious bacteria. He was willing to jeopardize his health for the good of medical progress. We could surely be willing to jeopardize some degree of efficiency in the short term to bet on Cord – and build it up from there. We needed to take a big leap headlong into the experience. Think outside the box and force ourselves to make continuous discovery work, even if the use case wasn’t simple or instinctive.
It took the courage and unbowing persistence of my co-founder to bring us to make that leap. After hot debates and begrudging acceptance from myself and the team, that doggedness about dogfooding paid off immensely.
Clack is the most ambitious application we built with Cord: a real utility, that has to work for us, on mobile and on desktop, at all times, in different browsers, resolutions and contexts, for the people from HR as well as the engineers who built it, and it did demand and trigger a ton of expansion, improvements and iterations on the SDK. It was a testament to how great the SDK was that the groundwork – the first usable version – came together in under a week. It’s also a surface we are guaranteed to use at all times but is built to use our staging code. As soon as someone commits anything in the codebase that breaks some piece of the experience, someone is sure to notice, and post in #clackless (our bugs and complaints channel) straight away.
This wasn’t the only or last experience we built with Cord. When we wanted to investigate building AI chatbots with Cord, we used our own tech to power the docs.cord.com search bar, the Cordy chatbot who lives to help you out in our documentation, and ask.cord.com – a Stack Overflow guru that delivers instant information on any technology. We had plenty of fun too, building a few games, like an AI-powered version of Werewolf (aka Mafia) along the way.
The Cord demo apps were also built with a mind to give as close to a real user experience as possible, so that every member of the team can imagine themselves working on another product - a document editor, design canvas, video editor, or dashboard - and truly relate to what it takes to build a great commenting and collaboration experience into these apps with Cord: not just toy examples and simple tutorials.
Effective dogfooding also helps you to catch errors faster. To do this you set up deployment so it hits employees for a day or two before it hits the broad population. At Facebook employees are set to get the latest version of the code first, before it goes live. We’ve adopted that practice here at Cord too. If anything is broken, we can see it, say it and sort it before it ever hits a real, live user.
Our ethos of practicing what we preach and being our own first users has expanded thanks to the fateful switch to Clack. We don’t look back and miss using Slack as much as we just add the cool stuff we miss from Slack into Clack. That makes its way to all of our clients as improvements as well. Cord’s clients can thank Clack for features like pasting GIFs, playing videos or link unfurling. And I’ve learned an important lesson on how far – painfully far – you should be ready to take the commitment of your team to your product – and how incredible the gains are on the other side of that in execution quality and speed.
Top comments (0)