We’ve been doing a lot of user observations and testing at Fluent this past month. It’s been an endless source of discovery and we’ve uncovered some valuable gems that have totally transformed our understanding of the landscape we’re playing in. It’s also taught us another important lesson of product. You need to eat shit. Every. Single. Day.
What does eating shit mean? It means putting out the smallest, barely working version of whatever hypothesis you want to test, and giving to a person to use in front of you. You need to watch silently as they stumble through your product, pick apart every line of copy and get confused & frustrated. Eating shit means they misinterpret your intentions, and tell you their honest take on your product. Basically, you need to fail in real-time with an audience, daily. Sometimes multiple times a day, back-to-back.
This failure can suck. It hits hard! You’re watching everything you’ve built get torn down in front of you. Except, these failures are what 5-star products are made of. And, there are ways you can frame it for yourself, and your team, so that each failure is the biggest win you’ll get all week. Each failure lays the foundation of success for your product & business.
How to frame your failures
When you’re out there eating shit everyday, it can weigh on you. It can weigh on your team. It can feel like you don’t have a clue what the hell you’re doing! It’s easy to get beat down. I’ve lived it. But often times, when you’re stuck feeling beat down, it’s because your framing of the situation is perfection oriented.
It’s easy to think your users will love what you built. You’re so close to it. You think about it so often and intensely. You fall pray to the trap of thinking it’s flawless. This means you end up eating shit unintentionally. You kind of expect to be told stuff doesn’t work, but you’re also expecting to uncover far fewer flaws than you will.
How we frame things at Fluent to avoid feeling awful is to book each observation with the goal to get shit on. We want to be told we’re doing badly. That doesn’t mean we’re building things with the intention of doing it wrong, it means we’re building our best guess at what’s right, with the expectation that’s it’s wildly wrong. With this framing there are only 2 outcomes:
- It’s good enough or great and the person has only positive things to say
- It sucks and they tear it apart, giving us a blueprint of what to build next
Neither of these scenarios is negative. Sure, one of them might hurt more in the moment. But if you don’t lose sight of the fact that you’re expecting to eat shit, it hurts less.
This framing is also useful when people on the team get caught up wanting to build “the perfect solution.” If someone has fears, or is operating on an assumption that X, Y, and Z will go badly, you can turn it around and reframe it to: that would be amazing if it did! That means your assumption was proven correct. But, until it happens, we’re stuck with Schrödingers feature. It’s either amazing or useless. We won’t know until we open the proverbial box.
How and when to act on your shit pile
It’s easy to get stuck gathering feedback. At some point you need to act on it. There’s no perfect time, there never is, but there are guidelines UX researchers have come up with, which is often cited as 5–10 session that contain similar feedback. A friend of mind once framed it to me in this way: the important stuff tends to bubble up. 5–10 sessions often gives you enough of a qualitative sample size to act on. This assumes you already have a strong definition of your target audience and that each participant fits that profile.
When you’re first starting work on a product, it’s much easier to get that cycle rolling. The issues are bigger, more obvious and often less nuanced. Those are your “core problems.” They lay down the foundation of your product. They’re often very tightly coupled to the core Job to be Done, which makes it easier for people to point out. After all, it’s the pain point they feel the most. As you continue fixing those core problems, the issues get more nuanced, and often more personal. In the early stages, it’s important to take those nuanced opinions with a boulder of salt. You’re trying to solve that core job for your core audience. Until that’s solved, don’t focus on any other part of the experience that doesn’t directly touch that job.
As you build on top of the foundation, the same process applies. The only difference is that the solutions tend to become less clear and require more intuition. As you venture deeper into novel solutions, the feedback you get from people will become less imaginative or directly applicable. That’s where you’re imagination needs to kick in. At each stage, keep these tests going, though. Even when you’re intuiting solutions, eating shit is the only way to validate them.
Why is eating shit so hard?
I think it’s one part ego, one part human nature. We like to avoid things that hurt our feelings, which, when working in product, isn’t a helpful aspect of our being. Thankfully, humans are adaptable. Eating shit is a muscle we can work out. I also think our aversion is largely dependent on the way we frame the situation. Getting stuck trying to build the perfect thing instead of a thing that we hypothesize will solve the problem can be a large factor in our emotional state, like I mentioned above. It’s taken me multiple failures and “trying to be perfect” for this to really sink in.
Eating shit as a process is one of those things you can read about hundreds of times, like I have, but until you actually experience it yourself it always sounds too-good-to-be-true. It doesn’t help that it’s tough to pull off, especially when working with a team. It’s not longer just you eating shit, but the whole team. And, you have to convince everyone that eating shit is good for you. You have to constantly remind the people building the product that it’s not perfect on purpose. A lot of work will be thrown out.
Getting buy-in to eat shit as a team
In my experience, it’s one part framing, one part proof. Ideally, you’re in a situation where it’s a small team trying to break into a new market. Or, a startup doing market validation. In which case, “building” is more a question of using rapid prototypes than it is actually building new systems. In some cases, like with Fluent, you already had a core part of the product built and human energy to throw at it. In instances like Fluent’s, getting buy-in wasn’t about committing to the idea of eating shit constantly long-term. It was about getting buy in for a short period of time to validate it’s value.
The way I went about it for Fluent started by dedicating 1 day a week to focusing on product instead of engineering. This ensured I could still support old product initiatives, while also validating certain market assumptions we had as a team. I took that 1 day a week and built out a “High Expectation Customer” profile along with their Jobs to be Done. This process took about a month. I started by reaching out to users who really loved us and booked interviews. Keeping my efforts to 1 day a week made it easy to get buy in from the founders to run this experiment, and gave me enough time to put together some documentation to support my findings.
After the founders sat with the information I gathered for a few months, they agreed to commit to focusing on these high expectation customers. Suddenly, we were firing on all cylinders to make it work. Instead of jumping straight to building for these people, our Chief of Product and I pushed for the “eating shit” approach of rapid iterations and user validation. We said we’d start with a 2 week window to see what we’d get.
We started by scoping our first iteration to fit the core jobs to be done and building the smallest bundle of features we could to put in front of people to test. It was far from perfect, but it helped us validate the foundation of our product. In those 2 weeks, we gleaned some the most impactful insights since the company’s inception.
This 2 week period is now our general product cycle, and will be, until we nail the foundation.
Getting buy-in is about committing to a smaller version of your ideal process, testing it out, eating shit and iterating on it. If it didn’t lead to any results, instead of giving up, ask for another 2 weeks with a different set of constraints. Over time you’ll find yourself oriented in the right direction.
Try to remember, the important things will always bubble up.