As a startup that builds consumer tools in health care, one of the biggest challenges our company, Iodine, faces is that the consumer isn't the paying customer. This means that, though we stress user delight and simplicity in our products, we must ensure that those virtues translate into something buyers--insurers and employers--will pay for.

This is a challenge for many enterprise companies. All SaaS startups have basically signed up for the do-si-do of dancing with two partners. It's been fascinating, if slightly alarming, to see how easy it is to stumble and step on toes. And it's especially remarkable to see how often startups make the mistake of thinking the end user doesn't much matter. They assume if they can get somebody to pay for their product, then certainly the actual consumers will use it as they are supposed to.

The end-user problem was made clear to me when I led a design workshop at a health care conference recently. Most of the people there built mobile apps for pharmaceutical companies to give to the people who take their medications. This is part of a broader strategy called "pill plus," and a bet that an app will prompt people to take their meds and refill their prescriptions as directed. The more refills, the more money for the companies.

I started by asking a simple question: Who is the customer? It wasn't supposed to be a trick question, but it vexed nearly everyone. Even though people knew who used their app--patients--they considered the company the real user, because the company was footing the bill. This means two things: First, their apps are designed to address the company's needs, not the patients' needs. And second, and as you would expect, the usage rates of their apps are abysmal. Such an approach may be a way to pay the bills in the short run, but it's no way to build a sustainable company. If the people actually using your product don't get value every time they touch it, good luck staying in business.

I call this the PeopleSoft problem. In my last corporate job, the HR department required all employees to use PeopleSoft to file expense reports, choose benefits, and so on. You couldn't concoct a better way to antagonize thousands of employees simultaneously. The software was clunky, the design counterintuitive, and the net experience hostile. It wasn't built for the people using it so much as for the people who were paying for it. PeopleSoft benefits from its entrenched user base and the inertia of HR folk. The chances of getting away with this today, though, are nil. No one is more influential than the people using your product. If they hate it, then you're done before you've started. Honor your users. All things begin and end with them.

You'll find that it takes exceptional discipline to stick to this rule, especially for startups. When you're chasing after customers, trying to get some revenue--any revenue--in the door, catering to the needs of the people writing the checks seems perfectly reasonable. As pragmatic as this might be, it can also lead to insipid features that aren't relevant to users, or require you to ignore users' needs altogether. If you've ever thought, "We'll make it more user-friendly later," let me assure you that later never comes. But if you honor your users from the outset, you will have a lodestone for your company as critical as any core metric.

One of my proudest moments came a few days after that design workshop, when I asked a new commercial partner why it had spent nine months pushing through a contract with us. "Because people actually use your app," she answered. "You guys seem to actually care about that." That this made us somehow exceptional shows how difficult it is to get this right.