The presentation had gone perfectly. In less than a year our team had turned the client’s demanding and complex set of feature ideas into a combination of products and integrations that we were all very proud of. Surely, no one else could have done this, in this time, and done it this well!
The board room was silent, in a very “what’d ya’ think of that!” kind of way. Then, the business owner across the table from me asked the most terrifying question possible:
I froze, speechless. How did the owner of this business, and now the owner of this brand spanking new, world-class technological marvel of a product, not know what to do with it now that it existed? Even worse, how did I not have an answer for what this amazing new product’s life should look like now that it was ready to leave the nest?
My team felt like we’d done our part. We were hired at an hourly rate to (presumably and contractually) write code and oversee the implementation of said code. We had taken a set of ideas and invented brand new tech. We had integrated with teams and systems all over the world. We had spent 18 months obsessing over and working on this thing, how could there not be a plan to make it a huge market success? This is the part where we’re all supposed to join the yacht club!
Spoiler alert: I’m still not a member of the yacht club.
The message was clear: Our clients no longer expected us to limit our involvement to developing software, no matter what the contract states. They expected us to ask them some terrifying questions with potentially uncomfortable answers to make sure the product was ready for this moment. The team, and the product, deserved better than the obvious lack of preparation from everyone involved, especially me.
Almost two years earlier, during (lengthy) contract negotiations, I had attempted to change our engagement model to one that supported adding our on-staff expertise outside of “coders” to this client’s work. In the end, the client simply wasn’t interested and I had failed. Ultimately, that failure had led to my failure to answer the most important question this client would ever ask me. As it turns out, a year of “success” had ultimately led to a conclusion of failure. We won every single battle, but somehow lost the war. The team had delivered technical wonders ahead of time and under budget, but we had failed to ask the right questions.
Learn from my mistake, here’s what I should have been asking:
“Is this a good idea?”
Everyone loves their own ideas, especially companies. There’s plenty of research as to why.
The first group of people to hear about a new idea are generally close associates who share concerns, viewpoints and needs. Empathetic, feeling humans are also apparently far less likely to voice a disappointing “no way” if they care about the person telling them about the idea. Add in the politics of corporate environments and the impact is only exaggerated.
If an idea is good, it will thrive in the face of adversity. No idea is born perfect. Ideas need to form and grow to learn to be easily communicated, they need to be nurtured, tweaked and then mature to apply broadly. Done enough times, some ideas can even grow to be great. Open markets do not care about your feelings, or your thoughts on your idea’s potential. Only great, fully realized ideas can survive life in an open market.
We were lucky, the idea we were working with was at its core a good idea despite our lack of an intentional vetting. But as is so often the case with chance encounters, our success was short lived.
“Is it viable?”
Our first failure was that, upon exposing the idea to a broader group with new expertise and viewpoints, we didn’t stop and consider whether or not the idea, on its own, was also a viable business.
Being a good idea and being a good business are two very different things. Want to know if something is a good idea? Figure out if people would love it if there were zero barrier to entry. Would someone use this thing if it were free and already directly in front of them? If you say “yes”, you may have the starting of a good idea.
Would someone spend 20 minutes of their time finding and downloading this thing to a device? Would they pay for it? How much? Is it enough to fund making the idea into a real, tangible, usable and attractive thing? Would someone move an icon on their home screen to make room for it? Would they recommend it to friends?
The results of questions like these are how an idea grows into a business. when you’re talking about a business, you’re talking about the things a lot of “idea people” like to avoid. Unfortunately, ideas don’t pay the bills unless they are surrounded with the trappings of a business designed specifically to foster the idea’s continued life.
We failed here. Without a plan of how the idea would grow up to pay for itself, we focused on features and testing in isolated environments.
This would come back to haunt us.
“How do we create it?”
If you’ve got a great idea that is also a viable business, you’re really onto something. Now how do you turn the idea in all of its (finally) matured glory into a tangible thing?
This is where business analysts, product owners, scrum masters, project managers, developers, testers and all of the other roles associated with implementation excel. This is where you start hearing about things like “Waterfall” and “Agile.”
These folks, and the processes they use, absolutely love digging into a deep log of work and creating something useful. For predictable results, that log of work should be precisely defined with no ambiguity. If you depend on these processes, or the people involved, to interpret things or read between the lines, then you’re asking them to either have acquired a second realm of expertise (likely it’s your business knowledge) or you’re asking them to do something they are ill-suited to do. Obviously, your mileage may vary on this, but in the implementation world, secondary expertise sets are incredibly unpredictable. If you’re betting on a software developer to understand the nuance of marketing, you’re betting against the house.
Even so, in our case we absolutely owned this space. Our team invented new tech, employed cutting edge techniques, adhered to and innovated methodologies, and pushed the bounds of patterns and architectures to make something truly special.
“How do we roll it out?”
This question is a sobering moment of divergence.
When you ask this question to a technical person, they will likely begin thinking about servers, production environments, testing, uptime, and the other trappings of something being “live.” This is the “How” space, and almost anyone who grew up in an IT or Operations world is fully comfortable here.
If you ask a marketing professional this same question, they’re going to start talking about market opinions, reviews, launch day announcements, creative assets, pr, social campaigns, media buys, and things associated with engaging humans. This is the “Why” space, and almost anyone who grew up in a Marketing or Business world is fully comfortable here.
Unfortunately, both worlds are so comfortable in their own space they very rarely reach out to each other. In organizations where there is effective work between the “How” and “Why” people it’s because of one of two things: 1) There is an effective liaison framework; or 2) The organization doesn’t internally differentiate between business and technology.
The catch? Both the tech and the marketing must be done well for your product to be a success. But very few organizations can do both of these things very well. In fact, if an organization is really good at both tech and marketing, chances are that you and I both know their name.
In the case of this product, this question got asked. In fact, it almost always gets asked in isolated circles. It’s asked either of the tech team (as it was in this case), or of the business team (which didn’t include marketing professionals). No one ever stopped and forced the issue on making sure all teams were united. And what a better place for the entire team to unite than at the point of finally having customers? It seems to be such a natural place to stop and get everyone together!
We didn’t get together, and this was the last chance for us to save ourselves.
“How do we improve it?”
This question is the grail. If you arrive at a spot where you have done all the other work this question is your happy bonus round. Once you’ve launched a product, you get to immediately begin learning from it.
Today, I’ll only cover the fact that the question must be asked, but be warned: The process of continual improvement is a vastly different process from invention. You’ll need a different team, different approaches and a completely different mindset to succeed here. And if you want to be great, you’ll need to learn to invent and innovate at the same time.
About six months after the product went live I was contacted by the client. Word had been handed down from his company that they would not be funding future innovation in the product.
Market acceptance had been phenomenal, more people were using it than we could have ever hoped and their feedback had been off the charts positive.
Awards had been won, market traction gained and along the way the complex tech and integrations behind the product had worked flawlessly.
By every measure, the product was a success… except for the one measure that mattered most. The product had never been taught to pay for itself. No one had ever made it a business.
Turns out, in absence of a better plan, the product was being given away as a “value add” to the commodity the company had made for decades. Sure, it drove sales up, sure, it got good press, but at the end of the day it didn’t have an easily identifiable and quantifiable income stream attached to it. That’s what companies call a “cost” — and it’s absolutely the worst place for a product to be. Costs are expendable, costs are to be cut whenever possible, and costs are a thing that have to be justified (at least) annually just to continue existing.
Our relationship recap research showed that users would have been willing to pay hundreds (and some thousands) of dollars per seat to have this product. These same users had a license to use the product for free, forever. The income that could have been generated from just the existing users would have been in excess of 12 times the needed budget to continue innovating in the space. Compare that to the ~7% or so profit the company was making.
The next day my boss, exasperated at the loss of the services business, shrugged across the table at me, “You said it all went so well, what the hell happened?”