In the following exchange, Flat’s co-founder and CEO, Seth Purcell (@seth), raises a big idea around how deeply influential B2B software can be for teams and how rarely that influence gets accounted for as ever more products get built.
— Niching down and around
— Prioritizing learning and word of mouth
— Avoiding the tempting path of only building for individual users
— How technology and culture drive user behaviour
Niching down and around
These are still early days for us. So we are always thinking about niches. We began as a dev tool and quite a few of our users are dev teams who don’t have a lot of formal processes.
The reason we started in that niche is because of my own background as an engineering leader, plus the fact that I know other engineering leaders in New York who had been using Trello as kind of the least-bad solution.
Our initial pitch was, “we can outperform Trello for the niche of software development” and we heard so much feedback from people that essentially said that we were strictly building a better Trello. We didn’t believe that for almost two years.
We also had non-dev teams using Flat and we kind of ignored them and filtered them out of our reports early on. It was only when we reassessed our roadmap, we saw that much of what we were building was around usability and quality-of-life improvements; not necessarily things specific to the software development niche.
So we gradually started pitching Flat to teams outside the dev space. And today we have many different verticals using the product.
A constant question for us is: which of these is the best one to focus on?
Given that our core message appeals to so many different types of people from so many different fields and backgrounds. Theater companies. Scientists. Agricultural services companies. Two-person companies to teams at orgs with 200K employees.
Niching, then, is a question of where we can be the most efficient in acquiring customers and who are best customers for us to acquire right now. So yes, it’s a constantly evolving process.
Prioritizing learning and word of mouth
Although I’ve noted that my existing network is where we began, we specifically didn’t want to sign up people close to us. Because getting users wasn’t a goal in itself – the goal was to test Flat’s thesis with the right set of people.
We really wanted to learn. Exclusively from people we didn’t know.
We wanted the as close to the undistorted truth as we could get.
So founder-led selling happened via introductions from people we knew to teams that were starting up and that were seeking out something that was simple, lightweight, and low-friction.
Then, as we branched out to find use cases beyond those of dev teams, we very quickly landed marketing teams that found our core pitch appealing. Then we took this deliberate expansion to other types of teams.
For the longest while, we’d just bump into someone at a meetup, talk about what we were creating without even approaching them as potential users, and they’d end up signing up for Flat. We’d have to pull in a good bit of restraint and admit, “although this is an interesting use case, we’re chasing a different hypothesis.”
All along, we’ve been searching for an intersection between people who have the problem, who are early adopters enough to see Flat as a solution, and those who are the most passionate about the intended purpose of the product.
Those who really get it.
We have teams on the free tier paying us voluntarily because they love the product and want us to succeed. We’ve had users who’ve read everything on our blog. Some others who’ve told their spouses about Flat.
That’s what we’re looking for.
Passion that can drive word of mouth and virality.
We’ve also been testing display ads on social media, newsletter sponsorships, as ways for us to target the right demographics and that’s been really informative.
When we see a new team onboard, we always reach out to them for feedback and assistance. That really helps us understand what messages are working and why people are choosing Flat.
We’ve recently seen a lot of sign-ups from designers, for instance. Both in-house teams and agencies. We’re talking to them now and trying to figure out why that is.
Avoiding the tempting path of only building for individual users
Thinking about the individual user, the team, and the manager has been a challenge. And it’s both a design challenge and a marketing challenge.
From the beginning, our vision for Flat has been that it serves the whole team.
It was never, “let’s focus on making something that serves the individual’s needs and expand from there.” That’s a tempting approach. But that puts people in the position of choosing/asking: “are you a solo tool or are you a team tool?”
The reason to say that one is building a solo tool, of course, is that it’s much easier for individuals to adopt a product than it is for teams. That’s not an automatic win, though. You’re just dividing the problem into two parts.
So we’ve been very explicit in saying that Flat is a home base for teams.
At the same time, we’re also cognizant of how these products are bought, who they serve best, who advocates for them, and how they get adopted.
We do have people using Flat on their own, in what we call the single-player mode. Those who’re transitioning from paper notebooks or a basic notepad app. We like that that market exists, but we’re not going after it.
It’s a beautiful proof point that illustrates that Flat is so simple, so effortless that individuals are willing to adopt it on their own.
This is in contrast to what we’ve observed with the competition, where, say, a Chief of Staff will assign a direct report to evaluate some existing options and demand, “we have decided to go with Asana, let’s get everyone using it.”
They’ll drive the purchase top down and often, because of it, usage eventually tends to fall off. Which isn’t surprising. This sort of adoption lifecycle risks being perceived as enforcement or compliance, that is getting people to comply with using it.
We don’t think that should be the case.
This category of software traces its lineage back to the early days of project management; they were simply tools for project managers to track what was happening with projects.
Then someone realized, “hey, instead of having the manager do all the updating, we’ll just make the team do it themselves,” and what you’ve ended up with is an imposition of more work that people need to do aside from their day-to-day jobs.
You’ve just distributed the work in the name of efficiency. People can tell that it’s extra work for them. To an engineer trying to ship code, anything else is simply busywork.
Hence the need for pushing top-down usage. There’s this clearly unhealthy dynamic of people reluctantly jumping through hoops to do work that isn’t core to their KPIs. That doesn’t help anyone.
Our philosophy has always been that Flat serves the team. And as a result of being a great tool for individuals in a team context, it also provides visibility to management for free.
It’s certainly a fine line to walk.
But we want to chase the goal of zero extra work for anyone using Flat.
Here’s what I mean by that:
You can assume that people will do the easiest thing. They’ll take the path of least resistance. What we’re trying to build is just that easier path (than currently exists) for people to collaborate.
As a result, managers get what they want. They can set priorities. Everything is tracked. No balls are being dropped. And you’re not having to hammer the discipline of the tool. It just happens emergently. That’s the sweet spot for us.
A reason why we feel our thesis is working is that we’ve seen several examples where teams have evaluated Flat and the manager has suggested something like, “I want to use a heavier tool because of reporting.”
And it becomes this huge battle between them and the team, where the team is like, “are you kidding us? It takes two hours to figure out that big-brand tool and we figured out Flat in minutes. Don’t do that to us.” 
How technology and culture drive user behaviour
You’ll often hear that the collaboration challenge can’t be solved by technology, because it isn’t a technical problem, it’s a cultural problem. Or a people problem.
There’s truth in there.
But we think it’s a bit more nuanced than that. Because technology has the ability to make things hard or easy. Your mention of behavior was exactly right.
Because behaviors are a function of both cultural norms (“what am I supposed to be doing, what sort of practices are embraced here and what practices are avoided?”) as well as what the available tools make easy.
There used to be a time without emails, right? We didn’t have all the behaviors that email made possible. Then we gradually had people spending all day in inboxes.
A few years ago, someone realized, “this behavior has some issues,” and so we got Slack. Now we spend less time on emails. But I feel like I spend way more time in Slack than I ever did in my inbox; it’s just so easy.
So technology creates the landscape of possible behaviors, and culture and behavior exist on top of that landscape.
For those of us who build software, our work is always at the interaction between those two. We’re attempting to shape a piece of technology that creates/shifts the landscape of behavior and some teams find that shift appealing enough to change how they work.
I have this book around here somewhere. It’s called Contextual Design. It’s the core textbook for people studying human-computer interaction. And context is the point.
People usually miss it because either they are focused exclusively on the tool or they’re focused exclusively on the team’s way of operating. No one is really looking at the interaction between those two things and what it means for the user’s wider context.
One of our core product principles is to focus beyond the boundaries of Flat.
We don’t just want to create a “simple project management tool.” We’re instead going after “a tool that simplifies the work lives of our customers by understanding all of their context, all of the tools that they’re using, and what they want to accomplish with those tools.”
Related reading from the Relay archives:
— Kairn’s co-founder, Patricia Bernasconi, on not building too close to user love
— Paperform’s co-founder, Dean McPherson, on choosing not to niche down
— Arcade’s co-founder, Caroline Clark, on the power of intuitive technology