We had no roadmap, no product, and no idea what we were doing. We shipped anyway.
How a two-person planning meeting in Chicago turned into a global product launch.
I landed at the O’Hare International Airport in Chicago with a few ideas, a memoir, and an allergy the aircraft ventilation gave me (forgot my pills, shame on me). I got through customs, took the Blue line downtown, arrived at my apartment, and used the rest of that Sunday to decompress after travel. The next day, I was ready to start.
I came to the office and went straight into a short, fairly informal planning meeting. It was just me and Joost. I led the product side while he was the team lead, yet with no team at that point. I shared my ideas. Immediately, it was clear we couldn’t finish either of them. At least not without help from other offices. We had to figure out how to make this team succeed.
In my previous company I built and managed a team of sixty engineers and product managers. It was different here. I came, inherited a team, got vague problems to solve, and a huge org to thrash. I doubted if I could ever build a successful product here. An offer to set up a new team overseas looked like a good chance to claim agency.
A month later, I flew to New York and came back to Chicago with a problem: the key components of our solution were owned by other teams in Europe. We couldn’t influence their roadmap but were completely dependent on them. Then an engineering lead in Amsterdam texted us with an initiative. My immediate thought: they want to turn us into a support team. Fragmented focus. No creativity. Just technical work. I spoke with Joost. We crafted a plan. Yes, we can handle this one thing. But it cannot become routine. That day I realized how fragile focus is.
Finally, I came to Joost with the personalized checkout product. He was concerned.
“We shouldn’t take this,” he said. “We don’t have enough people and don’t know anything about building AI products. I’m worried.”
“Don’t worry. We will figure it out,” I replied.
I knew this was the right product, the right opportunity. We didn’t know exactly how to do it, but that was precisely the point.
Forming
After speaking with customers, it was clear we can’t only deliver conversion improvements. We also need to report on the results, show them in a dashboard. An engineering team back in Amsterdam had bandwidth. But we decided to take another route.
I called an engineer in São Paulo, Brazil. Smart guy who worked with us on some minor projects before. He had the right skills, knowledge, but importantly he was a great fit for the team. Great character, willing to build new products, eager to learn. He was open to moving to Chicago.
Teams with bandwidth, right competences (on paper), and able to start working right away seem to be easy wins. Look how I solved the resource gap! Just a few reshuffles. But sheer availability never guarantees performance.
We didn’t, and couldn’t, hire the whole team straight off the bet. Value wasn’t clear but more importantly, the problem wasn’t clear. As we talked to customers, ran experiments, and relentlessly iterated, we unfolded the problem and formed a team around it.
I’d been thinking about this wrong until I read Team Topologies. Teams must be aligned with the value they should deliver, not grouped by expertise.
A self-sustained team needs to trade the benefits from the economy of scale for fast communication. And that’s on purpose.
When building novel solutions, reporting lines often kill communication. A data engineer discovers a technical gap, she leans toward a backend engineer. They might pull in a few other teammates. They discuss. They disagree. And eventually they resolve the issue. All in less than 30 minutes without touching calendars. If you’re in an unknown territory, those things happen daily. Now, imagine the data people are in another team.
We moved the guy from Brazil because he completed our team. But we only did it once it was inevitable, avoiding hiring for the bench. On his first day, he could add value.
You can never understand the problem fully from the get go. Keep the team intentionally small. Remove handoffs even at the expense of efficiency. Keep reframing the problem and reforming the team accordingly.
Focusing
When I was describing all the great things my team was working on, my manager stopped me mid-sentence.
“This is all great. But what’s the most important thing right now?” he asked.
What he meant was where the leverage points lie. Every complex system has them. The pieces that either make it or break it. Finding them is key for your team’s focus. How do you decide what’s worth solving right now?
From Gary Keller’s The One Thing, I got a practical tool to return my team to what matters. He calls it the Focusing Question and it goes like this: What’s the ONE thing I can do such that by doing it everything else will be easier or unnecessary?
Writing next year’s strategy, I was asking myself: What must a product bring to make a real difference in this company? I went on around the company, asking people from commercial teams, leadership, or engineering.
Eventually, I came to specific numbers. Revenue increase, impact on customer stickiness, and the most valuable customer cohort. That was my north star. No abstract metric. A very specific outcome that anyone from the board to the last engineer could understand.
In my team, it sparked the kind of conversations I didn’t hear before. During planning sessions, teammates started prioritizing experiments and initiatives against the outcome. They were asking: Does this initiative have the capacity to substantially contribute to our goal? The north star metric acted as a limit. The team didn’t need me or anyone else to kill their darlings. Ruthlessly, they did it themselves.
Driving
It was Friday evening, one engineer was finishing a feature we agreed to deliver that week. A few details were still missing. But he promised to share a demo with our colleague in Amsterdam. So, he pushed overtime.
“I promised to finish it so I have to finish it,” he told me.
It was around 7 PM, Chicago time. Amsterdam folks were fast asleep. No one overseas actually cared about the Friday delivery. The guy did it because the excitement of the work drove him.
Frankly, most managers care about their team’s motivation about as much as a two-year-old about their parents’ blood pressure.
Wondering how to get people motivated, I read the works of Robert Ryan, Edward Deci, and Teresa Amabile. They studied human motivation for decades. I found it’s about the right conditions. Their research explained what happened that Friday evening.
He knew exactly what had to be done. It was challenging but he had the right skills. The next step, recording a demo and posting in a Slack channel, was a meaningful milestone. The next week we mentioned the story during our standup and thanked him for his effort.
Becoming
Months after I came to Chicago, standing by my desk, I looked around. Three teammates were whiteboarding data pipelines. The data scientist was showing our latest experiment’s results to Joost. The designer was clarifying the user experience to an engineer.
Everything felt right. For this I had joined this company. This team. This culture. But a few months earlier, none of this existed.
We started with no team, no roadmap, no plan, and no product. Later, we launched a global product in a company processing over 1 trillion euros a year. That day, by the desk, watching my team’s creative flow, I wasn’t doubting my presence.
That day I became a chaos pilot.
Are you trying to do the same thing inside an org that wasn’t built for it?
You’re in the right place.