I've worked on a fair number of projects in my days, and I regret to inform you that we have found our way into a bit of a pickle.
In the old days of video games, you would work for months and years, crafting your best product and then send it off to manufacturing. It was out of your hands. Every decision, good or bad would show up on that disc. If you cared about what you were doing, and most people did, you worked way too hard to make sure that you put the very best product on that disc you could. Then you moved on. It was rare to get a chance to revisit those decisions, because even if you could fix it, you had no way to get it to someone. It had to work the first time.
Hardware to some extent still operates this way today. Though even the amount of opportunities to fix in software are greater than the past.
The combination of the flexibility of software with ubiquitous network delivery has allowed for a great many things, but one of them is making for some very difficult decisions.
Today, software projects take on two major forms. The hot new startup with an exciting solution to one of life's challenges. Or more typically inside existing companies a project to provide an existing service digitally. Despite sharing a lot of of similarities, these two types of projects get shunted into two very different approaches. Both approaches lead inexorably to this same point, a moment where you have a fantastic opportunity to fail your customers because done doesn't mean what it used to mean.
Let's begin with the hot new startup and see how they might get to launch:
You have an idea, it's a great one. One of those visions that strikes like a bolt of lightning, and for a moment you can see it in perfect clarity. You even know how to build it. From the moment you tell another person about this idea, you will be questioned. How, why, when? These are all good questions. You will need to answer them well enough to get someone to give you money, and from the moment you take that money the clock is ticking. Even though the world has validated your idea enough to give you money, structurally they are still predicting you will fail. Almost everyone fails, especially when you define success at multiples like five or ten in short time periods. The successes are few and far between, but they are so big they can afford to pay for your failure and the failure of ten others like you.
What they can't afford to pay for is the time and energy it takes to do it right, all the way. That ticking clock is covering your costs (if you are lucky) to prove a gate, show traction, get something off the ground. Your runway is short, and most of the time you are going to get one shot. You build the smallest, leanest thing that has meaning. That minimal product. You calibrate with potential customers so closely that you might as well just move in with them. Everything you see pushes you there, and you are told it's the safest path to success. That's sort of true. It's just not you they are talking about. It's the safest path for the money. It helps you to become one of those successes or failures as quickly as possible so you spend the smallest possible amount of their money to find out which you are. You do all these things to get to a launch, and you are lucky to have it.
For the company looking to improve an existing business with a new digital product, in many cases everything that happens is almost the exact opposite. People believe on day one they know the size, shape and rules of the business. The team is in place, the launch date is pre-ordained. The company is confident they know what the customers want because after all, we have been doing this for years. The project budget is the salary of the team, or the bid of the winning consultancy. There is a methodology in place and that Agility will allow the company to figure out those minor details along the way.
Fast forward a quarter or two and all that unsolved complexity has turned your small digital effort into a many tendriled thing that is clearly going to be much more difficult than anyone can have predicted. The solution starts to get chopped, and narrowed in a very painful way requiring the technical team to build less software and still hit a broad feature set. You haven't lived until you have spent a week discussing how cutting these ten unimportant features didn't actually help reduce scope. Teams persevere and keep their epics in priority order, quietly watching the cut line creep closer to the top of the original list than the bottom. Some businesses are just seasonal, we aren't date driven, except when we are. All your hopes and dreams for making this new product great are deferred, now you just hope to survive it. You do all these things to get to a launch, and you are lucky to have it.
Shipping something is it's own reward, letting something you worked hard on out into the hands of others comes with a special kind of hope and anticipation. It's great. As long as you were actually done. Back in the days of the disc, you may have been date driven, Christmas being notoriously resistant it's July relocation, but you were done when you were done. Unfortunately neither of our products are done at launch. They aren't done, but the team almost certainly is. Perhaps they are out of money or need to reach some immediate revenue goal to stay ahead of bills. Maybe they are just exhausted from a crunch to deliver. In most cases the team has put everything they had into their product, a product that is smaller, less interesting and more fragile than when it was conceived.
Those first users show up, and two problems emerge. First, something probably doesn't work the way it's supposed to; it happens. Second, you now have an order of magnitude more voices asking for things. Your idea is out there in the world, if you are lucky people like it, but you have stripped it down to the bones so of course they want more. This moment is often the pivot point, a moment when it could go either way. Your window for learning and responding to even a slight gap can be days or even hours, and at the time you need to be your best, you have nothing left.
I worked on a product once, it had a very market driven date, and a short timeline. The full set of corporate leaders bought into the idea that it would be thin, do one thing, and grow slowly. We could live with that thin thing for a year and spend that time to fill in the gaps everyone was painfully aware of. Instead six weeks after launch, all of those gaps needed to be closed, minimum viable wasn't. People hadn't imagined just how minimal it had needed to be in that tight timeline. It went poorly. The most heartbreaking part was that all the things people said we needed were all part of the plan, all goals on the list. Just lower priority than launch with features 1-5 on this date. The team had no energy left, and lost faith in their prioritization process. There was no time, and the buy in from leadership on the plan provided no cover.
Ironically it's the corporate world that could fix this problem more easily than the startup world. The startup money ecosystem being what it is, means that those teams won't get the time and money to do it right unless they find some form of patient money that doesn't seem to be all that common.
In the corporate world however, this is a self inflicted wound. Too often projects are planned with fixed dates, scope and budget. It’s usually not described this way, because that wouldn’t hold up to scrutiny, instead these constraints exist independently in the minds of stakeholders uncommunicated when they can be addressed without it being a crisis.
Often these interlocking constraints are not handed over to the team to optimize for, but held with ownership and decision making also diffuse. This makes it impossible for the team to make the kinds of trade offs required to get to any definition of success. A team can typically optimize for a very small number of things at a time, and only when they have a high degree of control over their key project variables.
Another common kick-off behavior is underestimating the amount of time and investigation a team needs to put in to start something new. Often a schedule might seem reasonable if the team has 12 months of solid development, but when the first three months of that development are spent on the team getting up to speed, building up context and figuring out all the details of what they are expected to build, that schedule just became unrealistic. The exhaustion and inevitable disappointment are baked in. Leaders repeat this mistake because they think that if they understand the project that everyone else does too.
In most cases the depth of understanding is limited to that leaders domain, and needs a lot of refinement before it can be built. Starting with a small fraction of the projected team size is a great way to avoid this early stalling and burning up your financial resources before you are ready. It won’t help with your schedule unless you get that small group started before the official clock is running.
Perhaps the most important opportunity for corporate projects is to build a mechanism for elasticity of expectations into the project from day one. Expand the definitions of success all the way to the top. Build into your process a mechanism to adjust in the clear light of day. Everyone should have the expectation that some trade offs between time, cost, and scope will be exposed at regular intervals. The team will be looking for support as they narrow in on the actual path.
If you have some immovable constraints like a maximum budget or ship date, carve out space within those to make some other elements less aggressive. Talk about what it means to do less with less to keep your risk envelope smaller. If you can’t get buy in on that, make sure you get those leaders to express their constraints all in the same room. Often they will create that space for you through their disagreement. If your CFO is limiting the budget, and that’s the constraint in scope, she can convey the seriousness of that to the head of product better than you can. They are senior leadership for a reason, I’ve seen cases where the politics were intense enough that a team just needs to present the constraints and ask do you all agree to set off a complete reset of those constraints. Failure to set up this flexibility almost always results in those stretches to reach some unsatisfying outcome.
Ultimately when you see this coming, the worst thing you can do is nothing. The longer you go without addressing it the more people will start to layer their definitions of success on the product, and the thinner your project will feel to them when they judge it. Your customers are going to feel that thinness too, and are going to expect you to fix it, or give up on your product quickly. Success requires not just delivering something that’s done, but also making sure you have the capability to meet the evolving expectations of today. If the business is strong enough to justify an investment, it’s worth the time to think through the long term investment and make sure your project supports that long term.
Subscribe to partialSignal
Get the latest posts delivered right to your inbox