Jared Shepard was working on secure military communications when his wife asked when she could have Hypori.
He wanted to know why she would want it. She was thinking about a different problem entirely.
As she understood it, losing a phone wouldn’t mean losing what she had access to. She wanted to take a big phone with good cameras to the kids’ events, then carry a little flip phone when she went out with her friends.
“Why can’t I change my phone out the way I changed my purse out?”
Jared had been thinking about people communicating in places where an enemy was looking for them. His wife was thinking about which phone to take to dinner.
She had found a reason to want the technology that had nothing to do with its original mission.
When you’ve spent years working on a problem, you become fluent in the reason your product exists. You know the benefit you’re trying to deliver. Your team can explain it almost without thinking.
Somebody else’s reason to want it can be harder to hear, especially when it falls outside the story you’ve been telling yourself.
He had a problem before he found the technology
Jared founded Intelligent Waves in Baghdad and grew it around doing IT in difficult places. Later, a general asked him to find a way for people to communicate securely in a hostile environment.
His team worked on concealing network activity and on accessing enterprise systems without keeping sensitive working data on the phone. One of his colleagues came across Hypori and thought its technology might help.
Jared called to ask about licensing it. The CEO told him he had been hired to close the business. The board was withdrawing its support and preparing to liquidate the assets.
Instead, Jared went to Austin to see the technology and meet some of the original developers. He bought the intellectual property for $1 million and hired six of them into Intelligent Waves.
He recalled that the remaining employees had about ten days before the company was due to close.
What gave him a reason to investigate was the job his team already needed to do. They could examine the technology against that job and work out what it would take to make it useful.
Hiring the original developers meant his team could draw on the people who had built it.
Jared said the team solved the mission problem. That was when he began to see how much further the approach might reach.
Privacy came from the way they solved it
Hypori, as Jared described it, provides access to a virtual operating system running in a data center. The screen is streamed to the phone. The enterprise’s working data stays in the remote environment.
The team had started with the assumption that the phone might already be compromised. The question was how to let someone work without depending on that phone being trustworthy.
Jared then realized something about the separation they had created. They didn’t need to know what was on the person’s own phone to give them access to the enterprise. That meant the person could keep their privacy.
“I wish we had said that we developed it this way on purpose, but it was really kind of a side effect,” he told me.
A design choice made for a difficult security problem had produced another reason to want the product.
The enterprise cared about protecting its systems. The person carrying the phone could care just as much about keeping an employer out of their personal life.
If you’re the employee, a presentation about security may leave a very ordinary question unanswered: what can the company see on my phone?
That is part of the product experience too. The person using it has interests that may never appear in the buyer’s list of requirements.
For a founder, there’s a worthwhile question here. What does your product let somebody stop giving up to get their work done?
When somebody describes the value differently, find out whether they’re giving the same benefit a more familiar name or pointing to a consequence you’ve barely considered. Those answers can lead to different decisions.
The next possibility still needs a customer
Jared’s wife took the idea further. She was interested in choosing a device for the occasion without having her digital life tied to one piece of hardware.
He had been looking at what the technology could protect. She was looking at what it could let her change.
She explained the appeal through something as familiar as a purse. She didn’t need his technical language to understand what she wanted.
Her question suggested a possible use. It left open whether there was a consumer market for it. Turning the idea into something people could choose, use reliably and pay for would require a lot more work.
That distinction matters if somebody asks for something that takes you beyond your current plan. An interesting request can become a whole new roadmap before you’ve found out how many people share the problem.
Start by asking the person to walk through the last time that situation occurred. Find out what they do today and what it costs them. Then speak to others in the same position.
If the need repeats, test whether the product can actually serve it. Look for people who will use it in a real situation and make a commitment to continue. Interest in an idea gives you much less to work with than somebody making room for it in their day and paying for the result.
You can investigate a larger opportunity while staying demanding about what you have learned so far.
A use worth pursuing still needs a team with time to develop it. Jared had to change the organization around Hypori to give it that room.
It was still inside Intelligent Waves. In his telling, the services business needed low overhead to deliver competitively, while the product needed investment in development. The two businesses kept pulling against each other.
He believed keeping them together would damage both. He appointed a CEO to run Intelligent Waves and spun Hypori out.
A founder growing a product alongside client work may recognize that pressure. The next project has a deadline. Product development requires spending now for something the business hopes to sell repeatedly later.
Jared chose to separate the businesses. For another company, the immediate question might be whether the product has a budget and a team whose time survives the next urgent client request.
Who gets to teach you something
We began our conversation with Jared’s life before either company. As a teenager, he had been homeless, sleeping in an old Lincoln behind a gas station. He said the memory still helps him avoid thinking he is better than anybody else.
When I later asked what he would tell a founder who had lost faith, he spoke about being receptive to mentorship from anybody. Someone who had spent twenty years as a janitor might have lessons he could learn from. Success didn’t make him too important to listen.
His colleague found technology worth investigating. The original developers knew how it worked. His wife described a use that was far outside the military problem he had been solving.
Each had something he needed to hear.
As a founder, you still have to decide where to spend your time. But first you have to hear the person well enough to understand what they’re describing.
Before your next product meeting, choose a customer who is already getting value from what you’ve built. Ask them to describe the last time they used it and the part they would miss most. Speak to the person using the product as well as the person who pays for it.
Compare their answer with the benefit you lead with when you sell. If they’re different, find out why. It might change how you explain what you already do. It might give you a new problem to investigate.