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.