Tag: Building Product

This my friends, is where the action happens. Not a big fan of military metaphors since I don’t have any idea what I’m talking about, but there’s one called no plan survives engagement with the enemy, or thereabouts. Writing this post caused me to look it up and evidently it’s a prussian quote, so it’s been around awhile, seen any prussians lately?

I digress. Bottom line though, whatever you thought you were going to launch with, this is not it. It may share a little or a lot with what you planned. The size of the drift is lessened or heightened by the skill of your implementation team, crossed with the clarity of everyone involved, and the feasibility of the timeline.

Short timeline, you’re cutting scope if you’re smart, nothing else to do.

Team not performing, if you realize it early enough maybe you can change something about the implementation team, otherwise cut scope or wait. And maybe wait forever, perhaps it’s was never possible.

Built the wrong thing, oops. That is on you, leader. This is potentially the worst of the three, you basically lose morale no matter what from here on. You need to now get clarity and explain to the team where it went wrong and what you were really looking for. Hopefully you’re not in this place.

Assuming you’re getting close to launch, and you’re committed to cutting some scope, the question is what. It’s pretty simple, anything that would cause the product to not work, that’s gotta stay. Every other feature, nice to have, design consideration, thing that causes support issues, all are in play.

When is it done? I always say done is a state of mind. More precisely done is when you’re ready to allow somebody outside to the development team to use it. Perhaps there is an executive demo, a group of beta testers, a “bug bash”, and a wide release. This should be encapsulated in an artifact known as a “Launch Plan” which should have dates, actions, and owners on it.

Each of those aforementioned stages could take some amount of time, you might find breaking bugs that simply cause the product to “not work”. Maybe you’ll find some you think, I could live with. Maybe there’s something that will schedule a bug in the future. Monthlong subscriptions looking at you. It’s probably controversial, but I’d make a tradeoff to get the product in the hands of users fully knowing you have a hard deadline to fix some behavior. It’s a known issue and these tend to be easier to fix because once you ship.

Shipping fixes all! Ok that’s an overstatement, but shipping fixes a lot, I compare shipping to an overinflated balloon which represents pressure. Shipping pops that balloon or at least unties the knot which held the fill tube closed allowing for the pressure to release gradually. Let’s explore that in the next section. – Post MVP

Ahh the early building phase. Probably the most objectively enjoyable part of the product development lifecycle. You have your team, you know more or less what you’re building, you were smart enough not to commit to a launch date yet, life is good.

The general positive vibe that accompanies this phase will often cause people to not critically measure the output of the team in this early going. But I emplore you to do so. Is development going faster than you thought originally? Good, means you might actually accomplish this in the timeline you wanted. Is it going according to plan, hmm. Might be cause for concern. But, you can see where I’m going, if you can’t get early wins here quickly when things are at their easiest, it’s going to be difficult as things get harder.

If you are in the second or third buckets, there are a couple of reasons you might not be getting the output you were expecting. The first is on you and the product manager. You didn’t account for complexities, and once the engineering team hit them, you’ve got more scope than you thought. This can lead to your team claiming scope-creep and that’s a quite demoralizing situation that just took away the positivity everyone had for building.

Second is complexity of the task. When the engineering team digs in for the first time, they start challenging the assumptions you and the engineering manager made in the definition phase. These may not pan out, and it’s really impossible to know everything before you start building, so you’ll have some amount of those to work out. A common phrase for those in unknowns. I would argue that the thing you should be most focused on in the early building section of the product development should be driving out unknowns. Once those are accounted for the predictability gained pays off huge dividends.

Third is ramp up. This is probably the best reason things are going slow. There might be some team members or all new to the software stack that you’re using and getting comfortable in the development environment takes some time. But looks for signs that it’s not a ramp-up problem but a much more serious issue, number 4.

Forth is talent. Low general talent levels from some number of team members can be a huge problem. One of the signs of this is simply things assigned to a team member simply don’t get done. There will be various reasons offered and they might even seem plausible. Look carefully though for the same issue for three or more times, and you’ll likely find it’s just a general lack of talent or effort. One of the worst parts about this is that the higher performing team members are stopped from building something that may be critical path, as in blocked from doing their part, by the fact that you’re trying to be inclusive of the lower performers. So in essence you are worse off having the lower performers than no one at all. This last fact was a discovery that look me long in my career to articulate.

Fifth and finally is environment. Some companies get into a point where the cruft of getting things built on top of the existing product is just painful. If a copy change is more than a trivial thing for example, that’s where the problem lies. You won’t likely get this fixed during the build of this particular product, so it’s a tax you’re going to need to apply to all things you build.