We were fortunate to witness Sugata's approach to solving problems first-hand on a number of occasions, it's elegant in its simplicity: when confronted with a question about the future of self-organised learning, he'd often respond "I don't know, why don't you ask the children?"

It's an approach which has been met with a fair deal of incredulity, but once you see how self organisation unfolds, and solutions emerge, from his research you realise that it truly embodies the scientific method: define what you don't know, design experiments to guide you toward an answer, and observe what emerges.

The more we listened to Sugata and his research team, the more we could see parallels between the world of scientific research and product strategy.

So we went all-in and put aside the usual phased approach to making products (learn, prototype, validate, build, repeat) and instead started to build the product that we were going to launch at TED from day one, without any real idea of what it was going to be.

All we knew is that we needed a technology platform which would:

Embracing this kind of uncertainty can be daunting, but getting comfortable with the simple assertion "I don't know" can give you the freedom to resist spending too long ideating, pretotyping and developing propositions; it makes it easier to follow a hunch, put something into the wild and learn from users engaging with real experiences.

You'll learn far more from this than any ideation workshop.

On School in the Cloud, there were three 'things we didn't know':

Creating a tangible product at the beginning of a project makes it easier to stay focussed on the experimental approach; it keeps discussions centred on the users and gives you a direct line to their experiences.

We were very fortunate to be in contact with a large group users from day one, but in order to engage them in a meaningful way and create a self-sustaining community of co-designers, we had to ensure that our fledging product provided enough value to keep them engaged for six months as we launched a series experiments and the product evolved from a simple scheduling tool to what it is today.

The product we gave over to our co-designers during the first week of the project. It aimed to help us understand more about the first objective (how can we help the Granny Cloud scale?) by providing a working tool to help Grannies schedule Skype calls with Sugata's SOLE labs in India.

Once we had something out there that users were engaging with, we adopted a multi-disciplinary Kanban process, tightly integrating design, research and development work.

Instead of starting the Kanban work flow with feature definitions, we started with a set of user requirements, or problems to solve.

It was important that we worked closely and kept the team small. No matter our disciplines, we all had to have a holistic understanding of the problems we were trying to solve so that each of us had the freedom to make implementation decisions (or rather, design experiments) while avoiding a design-by-committee mentality.

Taking a guess and putting it in front of a user was preferred over lengthy implementation discussions.

If a guess didn't solve the problem, we removed it, if it did, we kept it in.

As we learned from this direct experimentation, we uncovered more requirements and opportunities.

These "emergent phenomena" became our backlog for further research and experimentation.

Working in this way made it feasible to self-organise as a team and remove much of the formal processes required to keep a larger team on track. For example, there was no need to write user stories and estimate the work involved in making a simple blog, it was quicker just to roll a bare-bones blogging system into the product and let the users tell us if they wanted commenting, tagging, categorisation and all of the other trappings.

Daily stand-ups were replaced with short meetings during which we shared what we learned yesterday (not nessesarily what we did) and what problem we'd be tackling today. Prioritisation sessions became about deciding which problems were the most important to solve.

When you work small and close, design emerges from doing and evolves as you learn from direct contact with your users. Don't overthink, set the environment, design experiments and let the product evolve.

Embrace the uncertainty.