Magnus Carlsen, the greatest chess player of all time, smiled and gave us a thumbs up. “I think this will be good!” he said, and hung up the video call.
Six weeks later, the Norway Chess tournament would begin, and all we had at the time was a rough design sketch. We were going to build the game of Fantasy Chess where players bet on pieces and their movements in top chess tournaments. With more than 100 million registered players on Chess.com, the timing was awesome. If only we could build it in time.
We play a lot of chess at the office, but we had never built any chess products before. Now, we had 30 days to design, build, and launch a beta version of our game. Here, a simple MVP or clickable prototype wouldn’t suffice. In order to test the player experience and understand what value we would bring to users, we needed a simple but working version of the game.
Spoiler: we did it. It was teamwork at its best — fast, focused and fun. There are a lot of interesting things to say about what happened during those six weeks, but in this post I’d like to focus on the product management philosophy that got us started and kept us going — how the venture Fantasy Chess came to life and how we put together a high-performing product team that built a working version of the game in six weeks, without ever having worked together as a team before.
To be more precise, we didn’t put together a product team. Instead, we took a step back while word about our latest venture spread in the company.
Some employees were busy building other things, some were between projects, and some were on their way into new projects. But our company policy applies to everyone: during a work week, everyone is free to spend a portion of their time on whatever they want. They may volunteer to help an ongoing project or they could start new projects on their own.
Instead of negotiating allocation matrices, looking at employees’ backgrounds, running internal interviews, carefully balancing whose turn it is next, and all the other things that come with strict time management, this policy gave us something much more exciting.
Who will be so inspired by this idea that they will step up and start building it?
Most product managers use the Post-it note for notes and planning, as well as for running in workshops and meetings. Few, however, think about the original story behind the Post-it, and how it still is relevant to both product development and product management.
Born in 3M in Minnesota in the 1970s, it was another world famous product that came about by accident (or, as we will see, almost by accident). In an attempt to create a super strong adhesive, they got the complete opposite result — a bad batch of glue. So bad that it was hardly able to hold anything together. But product champions at 3M didn’t just throw it away.
First, they wanted to explore ideas for how such bad glue could power a new product. After some tinkering, they came up with a note you could easily stick to the wall and just as easily remove shortly after. The Post-it.
At 3M, managers were expected to have their people continually innovate. 25 percent of a division’s sales should come from products that were five years or younger. To make it happen, 3M employed a unique and to date innovative product management philosophy: they gave their employees slack in their time schedule — spare time at work — where everyone was free to choose what to do. They could come up with new ideas or products, or they could volunteer to support something that had already been started.
It was empowering and it was creative, and it made them fast. Exploring a “silly” idea like bad glue on a piece of paper wasn’t something that needed careful analysis or lengthy approval. Instead, people could go ahead and start experimenting with such ideas right away. This effectively moved the decision process of which ideas to explore downwards in the hierarchy to the same people who would do the explorative work.
It was a killer recipe.
Perhaps the best way to understand why it was so powerful is to imagine the opposite. Imagine you have an idea that sounds equally silly as the Post-It idea, but you are required to go through several processes, managers, and committees to explain the idea, make everyone believe in it, and ask them for their support and approval. The sheer work you’d have to do just to prepare for all the meetings and critical questions you’d get would make most people give up before they even got started. Your potentially super innovative idea would evaporate in your head before you had a chance to execute on it.
3M didn’t want this. Instead, they put enough trust in their people to allow them to control their time, self-organize, and set their own goals. Organizing like this was no accident, it was deliberate. But this deliberate policy allowed them to take advantage of an “accident” with a bad adhesive. It gave them the Post-it, which since long has been an indispensable product for individuals and companies all over the world. It has even become a word in our dictionaries.
At my company, Iterate, we’re inspired by the 3M story and we’re applying the same philosophy to developing software products. Like 3M, we allow slack in the organization and we use that to facilitate a self-organizing incubation process. This has resulted in many new products, but it has also built and strengthened our innovation culture. It has trained our people in taking initiative, taking responsibility, and in learning fast.
When you have an idea, you can’t go to a manager and ask for a team to be allocated to you. You have to find the people yourself. In order to further build this team, you have to inspire them, guide them, and onboard them on your vision. So, instead of managers promoting leaders, leaders have to promote themselves — by finding people willing to follow them and work with them.
When you have a team, you don’t have a lot of time available in the beginning, as most people will be on the team using their “spare time” only. So the team really has to spend those few hours they have together wisely. This trains everyone in working smart together by focusing on the few critical things that matter, and skip the rest.
In the beginning of product development, there’s usually only one thing that really matters: finding ways to prove that customers want your product. Working to prove your idea builds a strong sense of responsibility. It’s not about getting managers or higher forces onboard, it’s about surprising and delighting customers and markets — the real essence of innovation.
Many organizations forget that once the organization allocates people on a team, you also outsource this responsibility, because the organization, not the team, has decided what the team should work on. True responsibility and true accountability comes when people decide for themselves what to work on and how to work on it.
To scale this up, you need a strong sense of peer justice. People need to know that everyone around them is also working in the same way. When everyone trusts each other to follow this work ethic, you get an environment that it’s hard to exploit and hard to game. It’s an environment that comes with a built-in antidote to corporate politics, because it puts people over processes. This fosters the collaboration, learning, and creativity needed to build awesome products.
When the news broke in our company about Fantasy Chess, people who heard about the idea and felt passionate about working on it found together and volunteered to help out in whichever way they could. Both coders, designers, and a team lead (who had a background both in coding and design) came together, forming a cross-functional team that had the capacity to build the product.
They stormed, formed, normed, and started to perform in a matter of days. The first thing they did was to decide on a simple heartbeat: they came together every morning in a speedy status meeting, as a minimum effort to stay in sync. Even though some team members were experienced designers, everyone participated in designing the product and everyone was allowed to have opinions about design, tech, marketing, and other aspects of the product.
In short, everyone felt a shared responsibility of realizing the product as a whole. Most of the other tasks were planned and executed on the fly. Frontend development, backend development, communication, social media, onboarding of early users, and so on. Everything they did was grounded in experiences we as a company already had from building dozens of other software products (but never before anything related to chess).
There was a core team and there was a broader support group that chipped in when necessary. From our most senior profiles to the young and energetic. A lot of our people were tied up in other projects and couldn’t join the team full time, but whenever asked they helped as much as they could (without having to ask anyone for approval).
The final reason why this team worked so well, was that they had a clear goal: to build a beta version of the game in six weeks. Having a collaboration with the Norway Chess tournament and Magnus Carlsen also meant they had access to the network and expertise they needed. Both in the game of chess and in how the world’s chess community works. And finally, having a collaboration with Magnus Carlsen himself was a huge inspiration for everyone, and it helped the team and Iterate as a whole believe we could pull it off.
We were able to build the first version of Fantasy Chess in six weeks because we trust our people. When a new opportunity emerged, we took a step back and gave our environment a chance to respond. It came back with a super motivated, capable, and inspired team that broke all the records in how fast we’ve built something from zero to one.
There are many ways to organize for product development and innovation. Whichever way you go, there is one key challenge that is the same for anyone giving it a try: our world is changing faster and faster. What used to be true last decade, last year, last month, or even yesterday, may not be true any longer. This is the reason why experimentation and learning should be the foundation of any process, way of work, and company culture in order to succeed with innovation.
Inspired by heroes of the past, we increased our scope of experimentation and learning to the people and teams doing the work, by letting them self-organize and decide for themselves who they will work together with, and what they will work on.
It may sound like a fantasy, but we made it a reality.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
CPO and PhD Jen Wang covers “The Zone of Absorption” and why product teams are struggling to build when AI is shifting faster than anyone can keep up.
Explore four product team structures, when each works best, and how to choose the right model for speed, ownership, and clarity.
Learn how code-style reasoning helps product managers make sharper decisions, surface edge cases, and write clearer requirements.
A practical framework for product leaders to prioritize better, reduce noise, and focus teams on what matters most.
Learn more →
