How I'm using technical product tools to design analog experiences
Using technical frameworks to design non-technical human experiences
I didn’t join Hampton to build software.
I joined because there was an opportunity to iterate on a very non-technical, human product: Core.
Core is our flagship product. It’s a space where founders gather in small groups, month after month, to share openly, challenge each other, and build relationships that transform their lives. As someone who spent over a decade collaborating with engineers and designers to deploy software, I wanted something radically different, and more challenging than shipping code.
Yes, we’re tech-enabled. But what I’m building is something deeply emotional, and, when it works, transformational. The magic comes from the people, not a piece of software. And that was the draw for me. As the line blurs between human and robot, I wanted to go all human.
Funny thing is, I’m finding myself pulling out every tool from my software days to build this highly analog experience for our members.
It all still applies.
Last week I introduced my non-technical team to agile and sprint planning, and it got me thinking about how much of “traditional” product development I carry with me everyday. It’s really in bones. In fact, so much of what I’m doing now is about bringing the best of product development into a completely different context.
Side note: It’s also why I’m so bullish on product as the ultimate generalist career path. The skills you develop, discovery, iteration, prioritization, they translate anywhere. I feel real gratitude for that. Product trained me to test and learn. Those muscles don’t just apply to building software. They apply to building anything.
And so naturally, I wanted to share all about it.
Here’s how I’m using my technical product tools to build analog, human experiences…
Deeply subjective product discovery
In my software days, discovery meant shadowing users, running interviews and mining data. It meant running A/B and painted door tests to make really objective, quantitative decisions.
Today, quantitative data is much harder to come by. Because think about it: For one person, progress might be finally saying something out loud they’ve never admitted. For another, it might be realizing they don’t have to hold it all together, that it’s okay to ask for help. Both are “wins,” but they can’t be standardized into the same metric.
The “data” I’m working with is highly subjective. The insights I gather aren’t about features to build, they’re about creating the right conditions for high trust, radical candor and unwavering commitment.
I’m doing product discovery but how I measure what my customers are telling is me is completely different and unchartered territory, for me. I can’t wait till I master this so I can write about it more. For now, I’m fully in the thick of it, figuring it all out.
Agile, for non-technical teams
Agile was built for speed and adaptability in software.
But, code or no code, teams still need a rhythm. They need a way to triage what matters most, reflect honestly on what didn’t work, and commit to doing better the next cycle.
That’s all agile really is.
What really clicked for me was watching my team start to self-organize into sprints. Without any formal process or exposure to agile, they started working in bursts, rallying around short-term deadlines, like they were launching products.
That’s when I knew: if they already loved working this way, I knew I could 10x their output by giving them the right structure.
So I brought in agile lite: Sprints to provide focus, stand ups to keep us aligned, retros to learn and reset. Plus shared language, enhanced rituals, and repeatable frameworks so they could be more effective.
And we’re starting next week. It’ll be a learning curve that might slow us down at the onset, but I trust - after years of using these tools - that it’ll make us quicker in the long term.
It was an exciting moment to show my team the beauty of this framework, to validate their instincts to organize and to give them what they need to move more efficiently.
I’m excited to share more about how this experiment nets out.
MVPs and Iteration, Just Human-Sized
In software, an MVP is a scoped-down version of a feature, just enough to test, learn, and decide whether to double down or move on. At Hampton, I’m doing the same thing, just with people instead of code.
Recently, I laid out a vision for where I want to take Core Groups: a future where they feel more consistent, more transformational, and more distinctly “Hampton.” I shared that vision with my founders, and, in true founder fashion, they pushed me. Hard. The message was clear: this is the right direction, now move faster.
It was a humbling but helpful reminder. I don’t need to perfect the whole model on paper before I act. What I need is to descope. Strip it down to the most essential piece. Pilot it. Watch what happens. Then decide whether it deserves to scale.
That’s the beauty of building with an incremental mindset: resisting the urge to overbuild, and instead learning in the smallest possible increments.
The stakes feel different because the product is human. But the principle is the same: better to learn quickly and pivot than to assume we know what will work at scale.
AI As My Silent Co-Founder
Here’s the twist: while I’ve gone “all human” in what I’m building, I’m using AI at every step to move faster.
AI is my partner in discovery, helping me analyze interview notes, synthesize patterns, even draft documents. I recently asked it to bulletproof a strategy deck by coming up with all the hard questions my founders would ask to stress-test my thinking. I’ve weaved it into my work so much that they know what my founders will push me on. Wild.
At Hampton, I’m building an experience that runs on human energy. Our differentiator is analog. And we love it, because while the rest of the world digitizes, we’re running the opposite to direction to go all in on IRL.
I’m so excited to share more about what I’m building. But for now, I’m curious how you’ve used your technical product development tools outside of technical projects.
Did you try trello to organize a move? Did you try kanban to wedding plan? Guilty as charged on all accounts.
Hi - I’m Jori and I’m a Product Coach. If you’re Product Leader or on a Product team looking for support - drop me a note.