How much time should I be spending on my UI/UX? Does it matter at all for a B2B company?
When looking at a new product, it’s easy to “judge a book by its cover.” After all, comparing features and modeling ROI scenarios isn’t fun for anyone!
It’s much easier to assume that the well-designed product is probably the superior one… right?
This mental shortcut is the reason why I recommend all founders spend time on design and aesthetics—you can’t afford not to. There’s so many competing products out there, you won’t get traction if your app looks like garbage. 
Upon reflection, I’ve realized that feedback was a bit surface level. How does it account for the Salesforces, Oracles, and Adobes of the world? I wouldn’t consider any of them to be the apex of visual design… yet they continue to grow.
Did these behemoths come to power at a different point in time? Or is there something more subtle at play? What’s going on?
I think there’s a simpler, but easily forgotten explanation: a product’s UX will match the buyer, not necessarily the user.
To that end, there are two very distinct sales motions: ones targeted at practitioners, and ones targeting executives. No matter who ends up using your product, you have to satisfy the buyer.
For practitioners, the buyer is the user, and they spend all day in the particular tool.
If you sell to practitioners, you must put a strong focus on the user experience (and that includes aesthetics). After all, the user is the one who will ultimately determine whether it sticks.
What you build obviously depends on what your users need, but there are a few hallmarks that these companies use to really make the experience great.
native apps — work doesn’t just take place on your laptop. if you sell bottoms-up and haven’t invested in a native app, you’ll have a lot of frustrated users.
real-time syncing — wouldn’t be a drag if you had to refresh your app all the time to get some new piece of information?
keyboard shortcuts — this is a small feature, but many apps where users are expected to be in them “all day” rely on keyboard shortcuts to move around quickly (e.g. GitHub, Figma, Dropbox Paper)
collaboration-first — bottoms-up products often spread virally. Using the product has to be a team sport.
Companies which start at the low end of the market typically target practitioners first.
The top-down sales motion looks quite different. These companies sell to an executive who is not the user.
Interestingly, the UX on these apps often suffers. The editing experience is often clunky and time-consuming. Instead, these products focusing on solving the executive’s problem.
In my experience, the most common problem that executives want solved is visibility. You can’t fix problems if you don’t know where they are.
Salesforce is a great example of a visibility-focused product. If you think Salesforce is built for sales reps… you’re dead wrong.
No, Salesforce is built for sales managers looking to understand team performance. From the front-line managers to the CRO, you want to know if you’ll make your quarterly earnings target.
It’s no accident that this is the product picture you see right now on salesforce.com…
You might notice that a lot of cost reporting and ERP tools also fall into this bucket as well. Executives want to know what’s going on.
When you don’t have visibility, you are fumbling in the dark, it’s hard to even function. That’s why visibility is a first-order problem at the executive level.
I’ve seen this need for visibility again and again at Segment.
We spent months of engineering time building the reporting to understand where we had overspent on our AWS bill. When we weren’t sure of our sales forecasts, our analyst and revops teams spent two months getting them to a world-class level.
The second consistent problem executives want solved is enforcing compliance and standardization. There’s a ton of different security benefits and economies of scale if everyone does everything the same way.
Ultimately, there are a few hallmarks of top-down software
policies — the ability for a company to specify how the app should be used (permissions, data usage, audit trails, SSO, etc)
reporting — this one may seem obvious, but top-down products put a premium on exec-level reporting. built-in analytics and basic reporting will occupy large parts of the product real estate and messaging.
higher touch support — executives don’t buy products, they buy solutions to problems. a product alone might not cut it, but a dedicated account team will.
complex data model — bottoms-up products train users to work in a new way. top-down products must meet their buyer’s lengthy list of requirements.
Though I characterized this model as executives… it’s really anyone who wants extra visibility in an org. PMs wanting to close out sprints, Engineering Managers trying to understand productivity, or finance teams planning budgets.
Lessons learned with scale
As a founder, I’ve found it’s easy to fall into the mode of thinking only about the practitioners and the direct users of your product. After all, these users are your earliest champions, the people you’re talking to on slack, and the ones who are providing you the most feedback.
It’s far more difficult to make the mental leap from simply attracting users to attracting users and buyers.
There are three big lessons I’ve learned that I think B2B startup founders could heed as they transition from selling an individual to selling an entire department or company.
1: Know what your buyer wants to see
In Segment’s history, we’ve haven’t been as thoughtful as we could be around where to invest our product efforts.
We’ve always started from a mentality of solving the user’s problem. In the early days, this was 100% the right strategy. You can’t sell anything without achieving product-market-fit.
But, as we’ve shifted to selling to departments, we haven’t been clear about solving problems for the buyer, who is more often than not a Director, VP, or C-level exec.
In some cases, we’ve tried to invest in features for a top-down sell, while missing out on rather basic practitioner warts. In others, we’ve polished parts of the UI which honestly don’t matter to the actual buyer of the product.
Ultimately, you must know your user and your buyer, and understand the relationship between them.
The best litmus test here: ask yourself “what would one of my customers show their boss to demonstrate the power of my product?” If it’s hard to answer, make it easier!
2: Understand how your product spreads
Critically, there are two different models for how products might spread within an organization: vertically and horizontally.
Vertical product expansion happens when selling to executives, and critically it happens outside the product (think tableau email subscriptions).
For vertical products, you need to make reporting really really good. You need to be able to define clear lines between the parts of the org, showing visibility up, and enforcing standards down. Invest in dashboard integrations with email/slack, monthly roll-ups, and anything that spreads knowledge of your product capabilities.
Horizontal expansion happens virally and brings users together within the product (think shared airtable links or figma mocks).
Invest in invite flows, magic login links, gsuite auth, self-service onboarding, automatic billing, and share links that bring users together. Because the spread happens in the product, eliminate all barriers to get up and running with a new account.
3: Invest more in reporting than you’d think
This lesson is likely obvious by now, but if you haven’t invested at all in top-level reporting, you probably should. I used to think that reporting was more of a “nice-to-have”; a set of product features that don’t really matter for the user.
To some extent, I still think that’s true. Often, reporting doesn’t matter to the user at all. But it can make a world of difference to the buyer. And that’s the person who you ultimately will need to convince.
If you’re struggling to sell your product, take a hard look at your UI. Chances are good that you may be missing a key perspective; the perspective of the buyer.
Thanks to Osama Khan and Kevin Niparko for reading drafts of this post.
 : This was a big reason we valued having design as a core skillset of the founding team.