How Cadavers Could Help You Make Better Products

A few years ago, I went to the Bodies Exhibit in Miami, FL where donated cadavers are preserved and creatively displayed for educational purposes. The exhibit is a blend of science and art gallery, constructed to help people visualize the complex inner workings of the human body. In one room, you see what your circulatory system looks like in its entirety and learn there are about 100,000 miles of blood vessels in an adult’s body! In the next room, you see cross-sections of a brain and discover girls’ brains account for 2.5% of their body weight. Boys’ brains account for 2%. Hmmm…. Moving on through the gallery, you see a pair of lungs belonging to a smoker and the pristine muscular system belonging to an elite athlete.

What struck me most about my experience at the exhibit — besides the awkward awareness of my own mortality — is our very being is in a constant process. Even our bone cells are completely replaced every three months! And, in the case of the smoker and the athlete, external processes and patterns took their bodies down a path that wasn’t necessarily part of their body’s natural rhythms.

Outcomes are determined by our processes. As humans, we’re created with a desire to also create. So what creative process do you follow to achieve the outcome you desire?

At Life.Church our product team’s purpose is to build products that build people (metaphorically speaking). We want to leverage technology to support and enhance the life we believe we were all designed to live, and with this purpose comes a great desire for intentionality around what we are building.

It is not enough to do your best; you must know what to do, and then do your best.

―W. Edwards Deming

There are important elements to consider prior to projects making it on your radar: defining your product’s purpose, product strategy, GIST planning, setting OKRs and running effective ideation meetings (we call “Swell Meetings”) around your objectives.

The intention of this post is to focus more on a six-stage workflow we take a project through once an idea is worth considering. Just like the Bodies Exhibit helped me visualize the inner workings of the human body, my hope is that seeing our workflow — we call it “the D Process” — will help you understand how we focus on making better products.

| What problem are we solving?

During this stage, we are working through an idea, which can come from within our team, external teams, or user feedback. The goal of this stage is to decide on whether it is something worth pursuing, not pursuing, or seeking solutions outside of our product suite to solve the problem. During a discovery meeting, we answer the key questions below.

• What problem are we solving or what opportunity are we creating?
• How are users solving this currently? What is their current path?
• Are we the best team to solve the problem?
• How would we define the win?
• What metrics matter and how will we measure them?
• What teams will be affected and how?
• What processes exist or do not exist currently around this?
• What timeline needs to exist for this to succeed?
• Is there a third-party solution worth pursuing?
• Is there a budgetary or financial impact we need to discuss?

The team lead, product owners, and product managers will then decide if we are going to move forward with the idea and if so where it would stand in priority to other projects.

| How are we solving the problem?

We’re moving forward and in this phase, we get a plan together and create tasks for design and development to be able to run with clarity. We wordsmith tasks in the form of user stories to keep our focus on delivering the intended value to the user. For example: “As a user, I would like to be able to login easily with my Facebook account.”

It’s important at every stage to reiterate the defined win with everyone involved in order to keep teams aligned with what we are trying to achieve and avoid mission drift.

Key questions in the define stage are:

• Has the problem been clearly defined?
• Has the desired outcome been clearly defined?
• What are we building?
• What resources are needed?
• What functions must it have in order to accomplish the win?
• What are nice-to-haves?
• If applicable, who will manage content for this feature long term?
• Do we have all the user stories captured where we manage our work?
• Have developers offered input, weighing in on complexity and supporting solutions?

| What does the solution look like?

In this phase, designers will create mockups/prototypes and along with project managers will present, receive feedback, and hopefully gain approval from the product owner. This will allow designers to move forward with their work and allow developers to begin engineering. Again, it’s important to reiterate the problem we are solving and how the designs presented will solve it.

• Does the design solve the defined user problems?
• Does the design achieve the desired outcomes?

Some great practices in this phase would be gathering user feedback as well as any metrics to support the design decisions.

| Build it!

During this stage, we:

• Involve designers with our developers to consistently ensure what was intended in design is what we are developing, as well as to make any adjustments needed based off engineering solutions or limitations.
• Develop the necessary functions defined in our user stories.
• Create tests to ensure code is working across various platforms and use cases.
• Implement metrics tracking needed to monitor if this project achieved its desired outcome.
• Launch in a staging environment and implement necessary feedback from testers.
• Receive final “green light” from the product owner.

| Now, it’s actually a thing.

In this phase, you’ll want to make sure all communication has happened to all the key parties involved in its release. If possible, completing documentation on the feature as well as any training needed around it would be useful. As a team, you may decide on releasing the feature to only a handful of your audience and beta test it for awhile to get any of the unexpected kinks worked out and then deploy to your entire user base. It’s also important to make sure your marketing team around this project is in sync with your release date.

Hit the “Go” button and celebrate!

| Watch, see, learn, and improve.

In this phase, we determine if the project is, in fact, solving the problem and we look for any process improvements. If you haven’t decided these yet, now would be a good time:

• Who is responsible for reporting metrics and how often? Is there a dashboard we can keep in front of us regularly to monitor?
• When will we schedule a Retro Meeting? This is a meeting where we look back on the project and share what we loved, lacked, and learned. Then we commit to an area we will all agree to improve together. (If you work in sprints this can be done after every sprint cycle — and/or you can just schedule Retros around a project.)

To wrap it all up…

It’s important to lock down a process that works for you; just make sure the process doesn’t lock you down and you end up working for it. Staying flexible and adaptable is key to creating room for innovation and a team culture that is postured to act when an opportunity presents itself. And while this post is all about process, it’s really all about the people — the people we work in process with, the people we serve through our products, and the people who have unexpectedly and maybe awkwardly inspired us from the Bodies Exhibit.

May your body of work and team be blessed!

If you, or someone you know, would like to work in this process (and make it better) on a daily basis, check out our job opportunities at Life.Church!

Artwork from the Noun Project: Peter K., Marek Polakovic, Wojciech Zasina