At technology companies, Engineering and Development is the motor that keeps the product moving forward. Unlike real motors made out of metal, this one depends upon a lot of moving parts that are all-too-human, so it stalls a lot. A Development effort that sputters and stalls too often can lead to a product that falls behind the market.
It is vital for a Product Manager to get involved and hands-on with the product motor if it starts to stall. Product Managers can bring a different perspective to the Engineering team that can make all the difference in getting stalled development efforts started.
Read on below for some useful ideas that you can use with the team – from entry level programmers to VPs – to make your product develop and improve faster, and therefore gain ground on the competition.
[private]
Deadline Phobia
Developers tend to be analytical and thorough. They want to understand the details of how something is going to work before they feel comfortable committing to meeting a deadline. And very often they have lived the experience of receiving deadlines from on high that were set before anyone really understood the details. And such deadlines are very difficult to meet. Therefore many developers are understandably gun-shy when it comes to deadlines.
Product Managers have often had to plan their work off of Development’s deadlines, deadlines that were set before details and risks were defined, and which consequently slipped, repeatedly. So Product Managers have their own experience with deadlines and their own issues with them.
All this history of not meeting deadlines someone else set for you, and watching deadlines you were counting on slip past, makes any discussion about development schedules an emotionally charged one. Lots of people on the team would just as soon scrap discussion of deadlines entirely. But deadlines are necessary if work is going to progress in any kind of structured and predictable way.
And it needs to be structured, or developer time is not efficiently spent. And it needs to be predictable, because the efficiency of the rest of the company – Training, Consulting, Customer Support, Marketing – depends upon it.
The big challenge is how to commit to deadlines when they involve the types of unknowns that are unavoidable in software development.
Set-Asides to Cover Unknowns
One of the prime reasons why product development stalls is that the schedule doesn’t take into account interruptions to fix the inevitable bugs that nobody wants to plan for. But the bugs still happen, and they require engineers to drop what new development they’re doing to attend to them.
Since you can never know which bugs will occur, how many there will be, or how long they will take to fix, you can’t make estimates for bug fixing time by adding up detailed estimates for a total, like you might for new development work. Your best bet is to estimate a percentage of total Development time that will go to fixing bugs in commercial releases. Start by proposing 50%, and ask developers whether that’s too high or too low. Have them think back to how much of their time was spent fixing bugs in previous efforts.
It’s not just bug fixing from past releases that can benefit from the set-aside approach. One of the common estimating mistakes that software developers make is assuming that once the core new coding work is done, then virtually all the work is complete. As often as not, once the initial design is coded, you are only halfway there. This is because once others begin to review and test the design, there are a number of necessary changes and extensions that become apparent, not to mention bug fixes. So a Product Manager can encourage developers to set aside a hefty percentage – always bigger than they initially expect – for less-than-planned work on new capabilities.
Set Aside Lots of Time
You’d be surprised how much time needs to be set aside for such things as bug fixing, supporting the release rollout, providing support for Sales and Marketing, etc. It’s usually more than you think. As Product Manager, you can play a key role in making sure all the types of past interruptions and demands are brought forward into planning for the future.
By giving it a little thought, you can create a set-aside that everyone feels comfortable with.
In the end, setting aside a lot of time for reworks and bug fixes, if it turns out to be enough, saves time over the disruptions caused by unplanned delays.
Front-Load the Risk
Because so few people feel they can estimate risk and the likelihood of a specific occurrence, they fail to plan for it entirely. And then the development schedule gets thrown off track as soon as the first risk occurs.
Instead of leaving your schedule at the complete mercy of risk, it’s more useful to identify the risks, and specifically which ones are greatest. The greater the risk, the earlier in the development cycle you should place the work. The same goes for dependencies. They are a form of risk in that if work is not completed, the project that depends upon it is delayed as well. Put projects that are depended upon as far up front in the schedule as possible.
When You Can’t Commit, Do Research
Too many times, ideas for new development get stalled because there’s such a significant number of unknowns that it’s impossible to estimate the effort. Nobody wants to look like a fool by underestimating several times over.
More importantly, nobody wants to start a project for a reasonably good idea, but a capability that is far from the most important one in the mix, and have it morph into an enormous effort that drains more resources from product development than it’s worth. If it had only been clear early on that the fast way which someone proposed to build the new feature wasn’t going to pan out, no one would have spent time on it in the first place.
That’s where the Research project comes in. As Product Manager, you make it a specific category of requirement. Research projects are designed to investigate and try out the creation of new features so that by the time the next development cycle begins again, the team knows which approach will work, what the options are, and much more precisely how long it will take.
The focus of a Research project must always be practical. Have developers build prototypes or pilots and propose clear recommendations based on their experience of how things really turn out. And if it turns out that the prototype or pilot gets you most of the way there, roll it right into the current development cycle.
Hard Commits and Soft Commits
One issue that causes developers to balk at a proposed schedule is the fear that they can’t do all the work in the time allotted, and that they will be blamed for it. One way around the blame component is to designate certain planned features as soft commits, rather than hard ones. The soft commits are the first to drop off the list if there are delays. They are not hard and fast promises. Soft commits give Development some wiggle room, and properly set expectations in the rest of the organization, thereby helping the engineers forge ahead with their plan.
Of course, just because a certain capability is a hard commit doesn’t guarantee that it will make the release. But generally you can limit the drop-offs to the soft commits and maintain everyone’s confidence in the development scheduling.
Write Down Your Worries
Just like the experts suggest that one way to keep your worries from freezing you into inaction is to write them down, so too does this work for the development plan. Make sure that the risks and impacts are written down in black and white for all to see, for each and every planned capability. If nothing else, beleaguered programmers can point to a piece of paper and say “I told you so!” Shame on anyone who doesn’t read the fine print before signing on to the plan.
There will always be downsides to a proposed effort or a reason why it won’t work. The goal is to communicate these drawbacks and risks clearly and then aim for success.
Ignition Is the Key
As you can see from most of these suggestions, the important thing is to come up with a way to get development work moving forward, and keep it moving. As long as your programmers have assignments, priorities, focus, and structure, your development engine will keep humming along. Many of the tips here help provide structure or focus.
But once a development effort stalls, it takes a lot of effort, first to get it going again, then to get it going at full speed. That effort translates into a drain on management and developer time.
One Bite At a Time
The only way work actually gets done – as opposed to being talked about, criticized, advocated, or debated – is one piece at a time. The more daunting the development task, the more essential it is to cut it into small, easily digestible pieces to get it done. You can take away a lot of the intimidation power of a new capability by structuring it into phases and directing the focus to the first phase.
Use Customer Input
When discussing the requirements and merits of a capability, there’s the potential for endless debate about how things ought to work and what customers need. Often this happens in a vacuum, insofar as no customer is a direct participant in the discussion.
When planning or design momentum is stalling because your team is arguing, or over-arguing, about various details, there’s a quick way to get the answers on how things should work: ask customers. Organize a conference call or webcast to present the list of issues under debate to a representative group of customers and users. Get their consensus. Your customers will be flattered to participate.
When the customer group splits 50/50 over a specific choice, that’s a sign that, where possible, you want to incorporate both choices into your design.
Getting customer input is the fastest way to provide focus to a design effort.
Maintain Cruising Speed
By keeping individual development projects from stalling due to any number of common reasons, your development engine can maintain cruising speed. When you’re at cruising speed, the effort to stay at that speed is pretty routine. The more you can go at cruising speed and avoid stalling, the more ground you gain in the race with your competitors.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
[/private]