One the most rewarding things about telling a story that people want to hear is that, generally speaking, you get to tell your story a whole lot more. What attracted me to RevUnit in the first place was the freshness and uniqueness of its short, yet powerful story. Almost instantly, I knew I wanted to be a part of it. More than that, I was absolutely sure I wanted to lend a hand in crafting it.
In a much appreciated twist of fate, it’s a story that I now find myself telling quite often. Over the past few months, especially, I’ve spent a lot of time in conference rooms talking with folks about RevUnit—who we are, why we’re different, and what we do. However, it’s how we do it that distinguishes us from most.
When I tell people I work at a “product development shop”, typically what follows next is one of at least three different reactions: (1) Eyebrows raise circa Dwayne “The Rock” Johnson, (2) Eyes open wide, or (3) More often than not, a slumped, slouched posture instantly corrects itself. Simply put, people are interested. Agile product development isn’t new. What we have done, however, is put our own spin on the methodology. This is the point where I’ll make a horribly choreographed—but still relevant—advertising analogy. To borrow a line from Chick-Fil-A, “We didn’t invent the chicken—just the chicken sandwich.” That is, we’ve crafted a product development recipe that works for our team and our clients.
RevUnit was built for serious product development. Naturally, it follows then that people come to us because they want to build things—specifically, digital products. When anyone—be that client, colleague, friend, cousin, uncle, or distant acquaintance who simply knows that I “build apps and stuff”—pitches me a product idea, I tend to make four assumptions right off the bat.
1) You can’t afford six-month timelines with little or no value.
This is more than an assumption; it should be a mindset. From the beginning of the build, you should expect to see tangible progress (user validated feedback or iterative prototypes) on a continuous basis. Agile pulls value forward in the product cycle, establishing a continuous feedback loop that is used to further define product requirements, test alternative hypotheses, and define product strategies. Smaller, more agile cross-functional teams speed up product cycles, remove inefficiencies, and allow you to maximize value.
You’re not supposed to have all the specifics defined immediately. That’s okay. Traditional processes fall short because they generally don’t account for the unknown. Business requirements and product timelines are all crafted under the assumption that a product is concretely defined from the start. Agile assumes that isn’t the case. Rather than defining what we absolutely need to build, we’re using the scientific method to prove out hypotheses (or what we think we should build) through user testing and analytics. These learnings lead to changes or pivots in product strategies that otherwise would not have been discovered.
When you build a product, you naturally expect that people will use it. There’s an inherent voice in each of our brains that says, “If I’m building something for someone to use, then that person will use it.” It sounds farfetched, but it’s a fundamental bias of most product teams. For that statement to be true, it requires that people actually find your product useful in the first place. The problem is that most traditional processes don’t put the product in the hand of the user until it is launched and out the door. By then, it’s too late. Agile product development seeks to eliminate as much “waste,” (what users find unnecessary), by continuously soliciting feedback from real users to incorporate back into the product itself.
Users today expect product teams to learn from their suggestions and behavior and make improvements over time. There’s no such thing as “set it and forget it” in product development. Because of its fluidity, agile product development encourages a continuous product lifecycle -one in which user feedback is constantly gathered, rigorously prioritized, and then injected back into the product. This process enables us to zero in on exactly what users want, maximize your investment, and remove inefficiencies and excess waste.
I’ve found these four assumptions to be fairly universal, and perhaps, the best explanation of why you should care about agile product development. When you venture out of digital marketing and into product development, the technical prowess required to execute increases exponentially. Product development dictates that we think, learn, and build in an entirely different way.
Though the who, what and why will continue to evolve as RevUnit grows, the how is a piece of the puzzle that is fundamental to everything we do and will continue to drive our growth as a company. We’ve been fortunate enough to craft a story that people want to hear as well as bring together a uniquely qualified team to execute projects in a way that is smarter, more flexible, and more efficient for our clients.
There’s a lot to like about agile product development that I didn’t cover here. If you simply want to know more—or want to become a part of our story—feel free to get in touch.