Delivering on Promise

Every great organization makes promises and delivers on them consistently well. What happens when an organization fails to do this? The customer loses trust, and the organization loses morale. It’s like a punch to the stomach for both parties: a very real, very visceral pain.

When I was a kid, my dad taught me never to make promises I couldn’t keep. Integrity was everything to him. And that integrity is built on trust, in life and in business. The key to building a culture of trust is to deliver on promises consistently and reliably, over and over again, no matter how each team member is feeling on any given day.

To lay the groundwork for building this culture of trust, an organization should be able to answer the following questions with confidence.

• What promises are we making to our customers?
• How are we tracking these promises?
• How do we know which ones we’ve fulfilled and which ones we’ve fallen short on?
• What is our overall brand promise? How is it affected by the promises we make every day?

The tools needed to achieve good answers to these questions vary from organization to organization. Let’s take a look at what we rely upon at Praxent, as an example. We base our ability to instill trust on three major factors.

We Scrum

We track our promises in a very methodical way using the Agile framework Scrum. Now, I’m sure you’ve heard that Scrum is a passing fad (I’m told that often). But it works for us, perhaps because we’re seriously disciplined with our use of the framework, which is excellent for delivering on promises. According to the Scrum Alliance’s State of Scrum report for 2013, customer satisfaction is the highest business priority in Scrum, ranking well above speed to market, managing stakeholders’ change requests, and meeting budget.

With Scrum, we’re able to quantify the cost of the promises we make to customers and measure those against the balance of resources we have available to deliver on them.  A particular Scrum tool that holds magic for us is user stories. Just as Apple designs around people, not technology, we design for the value our project will bring, not around the project itself.

Here’s a taste of how we use Scrum. The description part of a user story covers these elements: As a [user] I want to [feature] so I can [business value]. Take this blog, for instance.

User Story: “As a blog author (user) I want to receive a notification anytime one of my readers comments on my blog posts (feature) so that I can respond in a timely fashion without reliance upon anyone else in the organization (business value).”

Breaking a project up in this manner creates bookmarks for conversations, instead of lengthy documentation. Each user story is assigned a Scrum Point using Fibonacci’s Number Sequence (e.g., User A = 5; User B = 8; User C = 1; User D = 21), prioritized by business value compared to complexity.

Based on empirical observation, we infer our velocity (our promise inventory). To stay true to this framework, we don’t ask programmers to estimate hours, we don’t exceed our velocity, and we don’t over promise.

We Meet

We’ve all been conditioned to believe that meetings are a waste of time.  That if only we could do away with meetings, we’d all be so much more productive.  In our organization, we’ve learned this cannot be further from the truth. Having a consistent, steady meeting rhythm with a reliable purpose and agenda has made us successful. We’ve learned that when team members meet collectively on a regular basis, the company can rise above individual inconsistencies. This, in turn, feeds our culture of trust. In our case, this means meeting at the same time every work day for 15 minutes.

First, the meetings help us assess each team member’s progress in addressing user stories. If resources seem to be strained in one area, we have a daily opportunity to shift other resources to address that constraint. Challenges are identified early and often.

Second, the ritual of daily meetings strengthens trust within our own team. Educator and author Paolo Guenzi recently wrote about this phenomenon in the Harvard Business Review, crediting organizational rituals for building shared identity, reducing anxiety, and reinforcing desired behaviors.

To carry this idea into your own corporate culture, ask yourself, “What meeting rhythm do we need in our organization to ensure that our promises aren’t falling through the cracks?”

We Imagine

By operating in the manner I just described, we are able to consistently fulfill our promises. But, going back to the first group of questions aimed at building trust, how does this all affect our overall brand promise? Think back to Psychology 101 and Maslow’s Hierarchy of needs, and then allow me to make a few modifications.

We discussed the base level needs: consistently making and delivering on our promises. That’s what your customers should expect from you each and every time you interact. A strong brand promise builds on this by, next, creating loyalty by meeting customer desires and, finally, creating evangelists among your customers by meeting their unexpected needs.

Figure out how to build trust by delivering on your promises first. After that, you’re free to dream big.

Want to learn more?

Find out how our product strategy process allows us to deliver on our commitments.