Unifying product, business, design, and development.

A frame-worked approach to building together.

The most challenging aspect of building products is the iteration of processes for individuals and teams within an organization. Your team looks something like this:
This is your team (I’m Tyrion).

From a development and design perspective, it’s key to nail down processes to create efficient teams, and even more so when incorporating business and product thinking into the mix.

So how do we collaborate?

It’s supposed to look something like this:

What we actually experience it looking like: Tower Defence

Tower defence, each camp taking a shot at the problem along the way…

This model is attacking the goal

Tower defence has a big chance of killing the actual goal / problem at the end of the game. That’s actually is the goal of tower defence.

Dead monsters going through the towers.
Imagine if the problem that you’re trying to solve is the monster. Then you have a lot of dead monsters. Shot by different arrows, but in the same places, from different angles, at different times. It’s inefficient.

Monsters are cute!

Stop hurting monsters.

Our independent processes aren’t *such* a bad thing because we strengthen our own processes, and scaffold them up to the team.

Our focus at Ci. begins with alleviating risks for the business behind our company through unified tools and processes.

We de-risked product design and development through tight frameworks to ground our processes. These frameworks find themselves living in project management tools like Asana, in our standard operations written on Medium, as well as within the design kits that we create to standardize the product processes.

Collaboration tools help us move away from Tower Defence, or at least buddy up in the same towers together…and that’s just one step closer.

For example, Google Drive gives you a document, but you can create a frame-worked template to problem solving in Drive, with a specific folder structure that everyone can follow.

Our processes might live independently across all of those tools, but our communication and alignment is unified through our frameworks:

  1. Decisions that are backed up by facts and research are sometimes viewed as subjective.
  2. We like labeling our processes.
  3. Some of us are perfectionists.
  4. We know what design thinking is.

The business success of our company as well as the clients that work with us hinges on maximizing opportunities and alleviating risks.

It’s a simple concept, and one that we do independently in our day-to-day, in groups, and during meetings. But even in agile and scrum, it’s not done consistently and contextually across all people and departments.

Our processes should explicitly unify our team against goals, opportunities, and risks for the business. And so this is what we’re actually working towards and what we’re talking about in creating our tools:

We’re addressing goals, opportunities, and risks across domains, through our own refined processes. It’s not the Product department, it’s the product’s contribution to the goals, opportunities, and risks department.

We bring these concepts the table through workshops. We have meetings. We take notes. We use evernote. You use evernote. I know you do. Or your Moleskine. Google Drive? Mac notes? We use whiteboards. And then we take pictures of the whiteboards.
I take so many pictures of whiteboards.

And then we translate these conversations as best as we can into our tools. Even if this happens, we can still get lost in the overall company mission goal in our day to day (something that you see people going around reinforcing as their full time job).

So we unify around a framework for WHY.

We’re scared of something at Ci. We’re scared of losing alignment day-to-day.

We’re scared of one single person being a hero and holding the guiding light to ‘why’ we’re doing something.

Them: “Why are we building ‘x’ feature?”
They: “Because it helps us seizing this business opportunity, and alleviating this business risk.”
Them: “Why do we need to start using ‘this’ tool?”
They: “Well, let me tell you. It’ll help us alleviate this risk in our product for our users”.

There are a lot of frameworks… here’s one that we use as part of our Ci. Kit.

From design, right down to technical decision making and implementation, our framework focuses on:

  • Project goal, story, opportunities, and risks.
  • Objective as milestones
  • Opportunities for the company
  • Risks to the goal from the users
  • Actions for the team, or for design and development to alleviate risk and seize opportunities.

Want to learn more about our team? Let’s Chat : mustefa@cfndrs.com

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.