For a testbed organization, entering into a pilot program with a startup is an opportunity to assess innovative solutions to thorny problems. But it also represents a substantial commitment in time and resources — so testbeds tend to select their startup partners carefully.
As executive director of the Institute for Senior Living, an AgeTech Collaborative™ testbed organization — as well as being the head of his own consulting firm — Scott Peifer has decades of experience working with startups in a testbed environment. He shared some of his experience with us, as well as some essential qualities that testbeds look for in potential startup partners.
This interview has been edited for clarity and length.
Would you introduce us to yourself and to the organization you’re with?
I’m Scott Peifer, and I lead the Institute for Senior Living (ISL). It’s a think-and-act tank comprised of CEOs in the senior care space, including senior living programs, organizations that focus on home care, and others. My own consulting firm, changAGEnts, facilitates partnerships between senior care organizations and technology companies.
We all know what a think tank is, but what’s a think-and-act tank?
Historically, ISL has done a great job of providing information to the CEOs in the group, who would then take that information and think about how to put it to use in their individual organizations. But as a group, we did some strategic planning and discovered there was interest in the Institute itself doing something, so we asked, “What is something we want to do together in this space to act as a catalyst for change?”
Can you share one of these initiatives with us?
One is a partnership we have with the UC Berkeley School of Public Health, and we’re also leveraging students in the Berkeley Graduate School of Journalism. The project is called Stories of Transition, where we interview aging individuals with the goal of sharing real-life stories to paint a picture of how to navigate the transitions that can come later in life. It includes video stories, written media and so forth, and there are distribution channels so people can access these stories. The goal is to give people a story-based way of providing guideposts and examples for navigating life transitions.
You have a lot of experience working with startups in testbed environments. What are some things that testbeds look for when evaluating a startup?
Whatever innovation that a startup is offering has to be extremely on-point to a problem that an organization has identified and prioritized to solve. The senior leadership needs to be enthusiastic about solving that problem, and the frontline staff who will be implementing the solution has to have the bandwidth to try something new.
I also think that, generally, a technology innovation needs to adapt itself to the care or service model of the testbed organization. There are times when some parts of a testbed staff’s workflow will need to change and adapt, but they are spending their precious time on trying new ways of doing things — and innovation is messy and takes time.
So a new innovation might be the perfect solution to a particular problem, but there are very real practical challenges to getting it implemented.
Even leading-edge, early adopter-type testbeds will hit a point where different technology products or platforms won’t integrate with one another. So the staff has to manage four or five different platforms, which first becomes untenable, then just absolutely stops productivity. It creates inefficiencies instead of efficiencies. At that point, many times the testbed will just pull the plug on an initiative or say, “We can’t do anything else.”
Many organizations do an analysis right up front and say, “This startup has an awesome solution platform. But does it integrate with our electronic health record system? Does it integrate with some other productivity system we have, like our staff productivity system?” And if the startup’s solution doesn’t integrate with some backbone system the testbed already uses, it’s a non-starter, because it’s too much time and effort for the staff.
Related to integration: A startup needs to develop enterprise functionality right from the start, so that a testbed organization can have a dashboard that can analyze data, give frontline staff visibility into everyone who is using the product — or whatever information is appropriate to that solution. It’s a tough challenge for startups, but developing enterprise functionality early on is key.
Startups already have their work cut out for them, so that seems like a heavy lift.
Testbed organizations are inherently risk-averse — for good reason. They provide essential, often 24-hour services to elders. For that reason, they don’t want to invest a lot of time, focus and money on a company that’s not likely to be around in a couple of years. You can never fully safeguard against that, but it’s important to realize that a common focus founders have — to land a “successful exit” from the testbed — runs counter to the interests of the testbed, which is seeking stable partners.
Two other expectations that testbed organizations have are that startups are able to do what they promise in the time frame they commit to, and that the terms and costs of the pilot don’t change part way through.
What else should startup founders keep in mind as they explore partnerships with testbed organizations?
Listen deeply to your prospective partner and to your prospective user. You know your product inside and out, better than anybody else, but you don’t know everything about the individuals who may be using your product or the organizations who are considering it.
#AgeTech101