Almost everyone who has spent time inside an organization has an opinion on what could be done better. They’ve had a manager they loved or hated, sat through a hard performance review, watched a friend get promoted. That perspective matters, but it only shows one side of the work.
HR leaders have spent years on the other side of those moments. They know what happens when a seemingly simple policy hits a hundred different circumstances. They’ve lived through the edge cases, and they know where the complexity is real and where it has simply become familiar.
We’ve said from the beginning that we’re building Sol differently. Some of that comes from the technology itself: new tools, a shorter road from prototype to product, and a core built agentically rather than AI layered onto a system designed without it. But the difference I keep coming back to is simpler. It’s who is in the room shaping our product and roadmap day to day. For us, that’s people leaders at some of the most innovative companies out there: our design partners.
I’ve been on the other side of it
My first design partner relationship happened before the industry had much vocabulary for it. It was the early days of “the cloud,” and I was part of an HR team evaluating a new learning management system. I worked for a consulting company that could see the shift coming. We had an opportunity not only to adopt something new ourselves, but to build the expertise to help our customers navigate the same transition.
We worked with a vendor that was rolling out their first cloud product. I traveled to their offices, expecting to sit in a room and tell them which screens or fields we wanted, and quickly found that was far less useful than helping them understand our work.
We shared our training materials, invited them into new-hire onboarding, and showed them where the software stopped and the workarounds started: printed materials, offline certifications, processes held together outside the system. Just as importantly, we showed them what we didn’t want technology to replace: in-the-moment coaching for a new college hire, the celebration of completing a leadership certification. Those were parts of the experience that were better because another person was there.
Ultimately, we kept the people building the software close to the work. And that experience is shaping how we approach Sol’s design partner program today.
Asking better questions
From the start, we asked a lot of our design partners: access to their teams, feedback on system design, even a look at their data.
We came into Sol having lived the experiences we are building for. We knew many of the frustrations of our customers. What we couldn’t anticipate was how quickly work was changing, and with that, the answers to key questions. What should a genuinely new set of tools actually do? Where’s the line between intelligence and surveillance? What does it mean to rethink hiring, retention, and development when talent has swung from surplus to scarcity, and people have arrived at very different expectations about what they put into a job relative to what they get back?
Some of that shows up in the obvious places, but it has been just as clear in small, easy-to-miss moments. Five months ago, one question could change the tenor of a candid conversation: do you mind if we use a notetaker? We’d feel the hesitation. The answers came back a little more polished, a little more self-censored. Over months of biweekly sessions we’ve watched that change in real time. The same leaders who once hesitated now wave us through, not resigned to the notetaker, but glad not to be taking notes and giving feedback at the same time.
That small change tells us something about how quickly expectations around technology are moving. Our experience as a founding team helped us understand which questions mattered. Our conversations with design partners help us to see when the answers are changing.
What happens in the hour
We ask design partners for roughly an hour every other week. The process today is straightforward: we work through a question, show what we’ve built since we last met, and let them see where their feedback changed the product.
We assumed the most useful feedback would come once partners could see Sol in action, and some of it did. The feedback got more specific: button placement, navigation, missing fields. All useful. But we also found that the screen could become the boundary of the conversation. We were getting better feedback on what we’d built, without getting closer to understanding whether we were building the right thing.
So we started spending more of the hour asking questions before we shared the prototype. Asking why, and then asking why again, basically playing the role of the bored four-year-old on a road trip. That’s when the conversations started to change. We got underneath how work happens today and why: which parts were necessary, which were artifacts of the systems people had learned to work around, and what our partners expected to change altogether.
And we started to discover something else. They didn’t always agree.
When design partners disagree
One design partner saw our chat interface and the context it held, and immediately pushed us to go further. She described her dream: you open your laptop in the morning and Sol is there. Not just for HR, but as something closer to an intranet, helping you understand what matters that day and giving you one place to start.
Another had a very different reaction to the same screen. We showed her the same chat that picked up where she’d left off: you started this yesterday, here’s where you were. She hated it.
Her professional and personal life was already full of systems keeping score of what she hadn’t done, and she didn’t want to open Sol and immediately feel behind. She described it as similar to opening Slack to nine threads demanding her attention.
We understood her completely. At first, though, these felt like two very different visions for the product. One wanted Sol to take on more of the work of orienting her day. The other wanted it to stay out of the way.
The initial reaction was to solve this disagreement in a familiar way: make it configurable. Configurability is the easy path; it’s an answer our industry knows well. One company wants approvals, another doesn’t. So you add a setting, give people optionality. But every toggle is a decision someone else has to keep making.
Do that enough times and you end up with the systems People teams are exhausted by today: enormously flexible, but enormously complicated to implement and maintain. That exhaustion is precisely what our partners describe when they describe the systems they have now. So we’ve made a choice as we build. Before we turn a stated preference into a permanent option, we try to understand what problem the person is trying to solve.
That brings us back to the issue our design partners were describing. Both were reacting to the same problem: cognitive load. Their feedback helped us understand a more useful question about how an intelligent system should use context.
Isn’t that part of the promise of an agentic system? Not just asking questions through a chat interface, but holding enough context that you don’t have to keep supplying it. The harder question is what the system does with that context once it has it.
More intelligence doesn’t always make the experience feel lighter. What deserves someone’s attention? When should the system use what it knows, and when does surfacing it start to feel like keeping score?
We haven’t settled every version of these questions, but we have gotten clearer on one principle: we don’t want the user doing all the work of deciding what context matters. Sol should take on more of that burden, and our design partners are helping us see when that works in practice and when it doesn’t.
Conviction isn’t a decision you make once
If the answer to every disagreement isn’t another setting, at some point we have to make a choice. We have to develop a point of view about how Sol should work.
That’s particularly true right now. The work we’re building for is changing while we’re building for it, and the expectations people bring to AI are changing just as quickly. Things our design partners were experimenting with six months ago are already becoming normal parts of how they work.
For us, conviction doesn’t mean deciding once and building against that decision for the next two years. It means having a strong enough point of view to move forward, while staying willing to revisit it when the work changes.
Design partnership has become one of the ways we do that. We’re not only asking whether someone likes the screen in front of them. We’re also paying attention to whether the assumptions behind it still hold, like we did with AI notetaking.
Our assumptions have a shorter shelf life than they used to. So this is as much prototyping as anything else. We aren’t only testing what we’ve built, but also whether our understanding of the work is still current.
Who lives with the decision
There’s another reason getting underneath these questions matters: every product decision eventually lands on someone’s work.
One of our design partners asked for a compliance overlay: if I’m drafting a policy that won’t hold up in the UK, tell me.
That sounds straightforward enough. But we kept asking: so what? Once the system tells you the rule, you know it. And once you know it, choosing to proceed carries different weight. One partner put it simply: once you know, you can’t go back to not knowing.
Then someone else in the room pushed it one step further. The issue isn’t only that you know. It’s that the system now knows that you knew, and potentially holds a record of what you decided to do anyway.
We spend a lot of time thinking about how much context an intelligent system needs in order to be useful. But there’s another side to that: what it means for the people using it when the system can remember more than the systems before it.
If people know every question, draft, alternative, and decision could become part of a permanent record, they may put less into the system, not more. More context could ultimately produce less trust.
We don’t think the answer is simply to make the system remember less. The harder question is who gets to decide what’s kept and who can see it. We’re still working through the specifics, including what Sol should capture and how much control an organization should have over that record. But we know we’d rather work through those questions now than discover later that we made the wrong decision for the people using the system every day.
Who is in the room
All of this comes back to who is in the room.
Our design partners opted in, and many came through our own networks. They are often senior People leaders, which gives them an important view of the organization. But it’s still one view.
We’ve seen that inside the sessions themselves. A People leader, an HR operations lead, a manager, an IT leader, and an employee can experience the same process very differently. A time-off request looks different to the employee taking it, the manager planning around it, and the benefits administrator responsible for making sure the policy actually works. Those aren’t perspectives we want Sol to flatten into one answer. They’re the context the system needs to understand.
The same has to be true of how we build it. One of the things I’ve appreciated most is how willing our design partners have been to bring other voices into these conversations. But we also know we need to keep expanding who we hear from: more skeptics, more people who use these systems every day, different roles, and organizations that don’t look exactly like the ones we know best.
We’ve said from the beginning that we’re building Sol differently. I understand what that means more clearly now than I did when we started. The technology matters, but so does continuing to put our assumptions in front of the people living the work day to day, and changing course when they show us something we missed.
The commitment isn’t that we’ll always be right. It’s that we’ll keep making sure the right people are in the room when we decide.
