Bringing a new product to market is always a difficult and challenging task. You need to conceptualize the journey from the eyes of your users. Understand their pain, and design how to solve that pain. You need to understand how your solution will get into their hands, and how they will use it. Asking why would they even spend a second of their time trying to understand and use an arcane new tool?
We are only getting started here. Once you conceptualize and design your product, you need to actually get it to work.
Getting it to work means engineers, developers, architects, 3rd party APIs, and all goodies in the cloud. You have to break up the designs and business logic into digestible chunks that can be understood by devs. Those pieces in turn are further broken down into developable morsels. Now, we can write the code against those tiny crumbs. Once the branches are written from the atomic lines of code, you need to integrate everything back up again. Test it, iterate, deploy it — and maybe, just maybe, you’ve got a product people are willing to buy and use; because it solves a painful need.
Building a product is like forging a chain, one link at a time. Each link is dependent on the one before it; however as teams work, everyone is focused on their local link and its easy to miss the end to end chain.
This hourglass of moving from the high-level concept, down to the nitty-gritty code, then back up again to working software is an insane ride. Critically, no one person can do it all (well maybe that flappy bird app is the exception). That means you need to hire/build a team of diverse people. Each much smarter and a more experienced expert in their domain than you will ever hope to be.
Each a specialist. UX designers. UI designers. Software architects. Data scientists. Back-end devs. Front-end devs. Mobile app devs. Growth folks. QA. Devops. And guess what? As specialists they all see the world filtered by their experiences, expertise, and frame of view. They must see the world according to what the product needs from them; it’s hard to focus on your work otherwise. Often, their world views are in contradiction to each other.
Now; we layer back the limits of time and budget. Not so suddenly, it becomes clear why many product launches — either at a startup level or within a mature organization — fail or ship late/over budget.
With this rambling introduction, the key question that I keep asking myself, is how do we avoid product shipping failure? How to ensure that my co-founders and I — all non-specialists in almost every field needed to build a product — How do we keep a diverse crew of doers and thinkers aligned to the ultimate goal of getting to the hands of the user a product that solves a need?
The agile movement has in starts and sputters attempted to solve this problem. But agile comes with its own problems — mostly in that people apply it without really understanding why they are applying it — which breaks all the philosophy laid out in the agile manifesto.
In my career, and especially now at Baselane, we have attempted to simplify how we come together even further. It’s so simple that at times when I cannot sleep — because I recall all my past product failures — I wish at times could go back in time to whisper one word to my past self: Negotiate. That’s really all you need to have a decent product launch. Where negotiating is the skill of being open to another party’s goal; and either concede to the middle ground, or change your or another’s point of view.
I want to point out this is dramatically different from a debate. In debating, you discuss different points of view. In negotiating, you can debate, but you must always leave the discussion with a shared conclusion or next steps. Always.
Since you need many types to build a product, types who do not share the same worldview and often do not see eye to eye, as leaders of that crew, our primary job is to both facilitate negotiations on the objectives of each team — and be open to negotiations ourselves. We need to ensure open communications to cascade changes from one end of the development chain to the other. We typically use the backlog coupled with the visual designs as the primary mode of conducting such negotiations. There is never a direct message from any one person or ‘authority’ to do it this way or that.
We surrender control to the experts in each domain, we build processes that allow them to communicate and negotiate — and we keep the focus on the process and user. We work hard to remove any arbitrary source of truth/power.
That way I have found, the entire team is always engaged, empowered, and trusted to focus on the end result. That in essence is our culture and the foundations of our processes. It is why I am excited to come to work every day to learn and lead and build. It is a significant reason why I know we will be successful in addressing the needs of our users one way or the other.
