From humble beginnings...

Simple things can give rise to enormous complexity.

• The same 4 DNA bases and 20 amino acids make chickens, humans, tulips and whales
• Transistors just switch on and off but enough of them can now mimic human intelligence
• The interactions between 4 fundamental forces give rise to all of physics

In field after field, discovering and deeply understanding the right "atoms"--the right building blocks--to describe the complex phenomena we see creates an explosion in our ability to shape our world.

But every product is unique, right?

It would seem that each software product is a bespoke beast, with SaaS apps made of completely different "stuff" than a consumer marketplace. Just as it wasn't obvious that the same building blocks and processes produce humans and slugs or that just 4 forces account for everything we see happening in our Universe, it's not immediately obvious that there are universal building blocks for products.

But if there were atoms of products, surely we would want to use them, right?

In field after field, thinking small, from the atoms up, has yielded huge advances in our ability to build big. We think that product building is no exception.

Atoms of products

It turns out that there actually are a small set of atoms that all products are made out of.

And that's what we put at the center of Team Pando.

We can make every product out of:

• States or steps. A product is in one or more state(s) at any given time and the states determine what the user and product can do.
• Events. Events are anything that a user or external actor can do. These are things that our product might want to respond to in some way. Clicking, tapping, typing, etc.
• Conditions. Conditions determine how our product will respond to a given event. For instance, you may want an "is valid" condition determining what effect a form submission event should have.
• Actions. Actions are things that the product can do. Saving data, recording events, messaging other systems.

And we've found that there's one additional atom that really helps us stay at a comfortable level of detail while we're specifying products:

• Expectations. We can be explicit about how we expect our product to represent certain states.

That's it. With those building blocks, you can describe any product you've built or interacted with.

What about the UI?

So you actually want to interact with this product you're building? ;)

Our building blocks just specify the different steps that a product has, what's expected at each step, and what the user and product can do at each step. But we haven't mentioned anything about how users actually do those things yet.

The answer is fairly beautiful: the UI is determined by which state(s) the product is in. Think about it: the state determines what a user can do, it has associated expectations describing how the user might do some of those things and it comes with a map of where the user can go next. That sounds a lot like a design spec to us! That's why we connect designs to states in Team Pando.

Our transistor moment

We have found that representing products this way has huge benefits.

We can build up a common vocabulary across a team.

We can be perfectly precise in talking about our products.

We can connect everyone's work to the same blueprint, keeping teams tightly aligned.

We can generate documentation, walkthroughs, help content, tests, and code.

We can identify inter-team overlaps and conflicts while everyone is still in the ideation phase.

We certainly didn't invent this model (you can learn more about state charts here) but we are big believers in its ability to help us think clearly, together. Try out Team Pando with your team and tell us what you think!