The Most Important Product Feature

The key ingredients of a successful product launch

Bob Cagle is productOps co-founder and CEO. Twenty-two years of experience in the trenches have not blunted his natural exuberance and optimism. Bob thinks better near a whiteboard, is a wizard with Excel, and believes there is an entrepreneur in everyone.

From Waterfall to Agile, experts have grappled with various software development processes to create a predictable outcome. In my experience, no process works reliably once theory replaces practice and people are placed in the mix. People introduce all the uncontrollable variables that processes fail to consider. From the developers, architects, designers, product managers, the product owners — not to mention the management team, VCs, customers or clients that take possession of the product — everyone has an opinion about what’s important. And there is no shortage of people that are keen to put their fingerprints on the success of the project. In and of itself, this involvement could be seen positively as commitment or ownership but without guidance that leads to good decision-making it’s a recipe for the worst thing that can happen to any project — missing the deadline.

Don’t be late

Missing a release deadline results in a long list of obvious and hidden problems. Not the least of which is overrunning the budget and missing the revenue associated with shipping on time. There’s also the ever-expanding expectations of the stakeholders including the users and the press. Internally rumblings such as “Since you’re already late, shouldn’t you be able to add MY special feature?” might be heard. In all but the rarest of cases the market won’t miss that feature. They will only remember that you were late.

Nine out of ten

We have a lot of axioms at productOps, but “nine out of ten” is likely the most common. It’s better to deliver nine out of ten features on time than ten out of ten a day late. It includes a lot of assumptions, particularly on where to draw the line from the onset of the project, but as my grandfather used to say, “if it were easy, everyone would do it.” Clients, both customers and users, assume that you are building the right product. There have been lots of conversations, you have asked lots of questions, and maybe you have even done the right thing and led the project with design up front rather than the continually repeated the rookie mistake of trying to “making it look pretty at the end.” The advantage of leading with design is the client can see what the product might look like and actively test early iterations amongst their team or end users. But the one thing the client needs to be able to count on is that it will be released when you said it would be. They often are coordinating all kinds of product-related schedules that you cannot see; marketing, advertising PR efforts, and manufacturing and channel schedules some which may even tie into to investment tranches. The consequences of missing those deadlines could put your company out of business. Imagine failing to get your IoT product into the channel on time for the holiday season when over 40% of your annual revenue depends on that. Your competition just said, “Thanks for the lunch.”

When it goes wrong

When you look back on a late, failed project, there is plenty of blame to go around. Did you prioritize ALL the features of the loudest voices in the room? Did someone refactor that pesky (but working) subsystem because of the shiny new technology friends said would make it so much cooler? Did the team try to squeeze design in as an afterthought? Or, one of my favorites on really big projects, did you resort to the Big Bang Theory by waiting to integrate all the major subsystems until right before release, overconfident that it would magically work?

Often clients will come to us incredibly sad and frustrated right after one of these catastrophes. Their coffers are drained, their reputation has been damaged with the finance department and investors, and they have taken a credibility hit with their users — often in social media and the press.

The “Wits End” meeting

It’s not uncommon for us to meet a new client after having been through the experience described above. We call this the “Wits End” meeting. After hearing their stories, my diagnosis is typically the same. They failed to get ALL the humans on the same page about the all-important release date.

Sounds like a simple concept to get across but how do you do it? Over twenty years ago, my co-founder and I found that if we started off with real software that demonstrated the essence of the product, things get off on the right foot. The client could touch and experience what the user would experience. They could correct communication misunderstandings. They could focus on what was important because they were closer to the cycle. It didn’t always work out like this, but we learned that when it didn’t, it often meant the client was not clear about what they wanted. It happens. Some people, let’s call them hand wavers, are all about the vision and not about execution. Much of what we had been doing over those years would later be called Agile. Software over specs.

Agile before it was agile

Our first read of the Agile Manifesto evoked mixed feelings. It was like someone wrote down what we had always been doing. On one hand, it was validating. On the other hand, wasn’t everyone doing this? Apparently not. There is nothing more important at the early stages than understanding WHY the product is being built and getting everyone’s agreement. That should prioritize any feature of the product. Next, have design be a sprint ahead. The design team should be working on high-res designs from the outset and be ahead of the development releases. Then, get software working within the first three sprints and keep it working for the remainder of the project.

Show them

Clients might discover an assumption was wrong after showing the users the software, but if you receive that message early enough you have time to make changes without unwinding half the project. People need to see things in action. They need to experience it — the feel of it, the flow, the delight or dismay. This helps to validate the understandings of the conversations that you had. And lastly, it is imperative that you attain agreement on a date for the Minimal Viable Product (MVP) so you can agree to delay the development of lower priority features to a second release. This sets the stage for a compromise based on the most important, agreed upon feature for everyone. Shipping on time.