“Code-and-fix” development is the most common form of development for companies with fewer than 20 employees and is therefore very common in start-ups. The phrase describes a process in which the feature set for a product is developed at the same time that the engineering team is coding it. It’s quite flexible and often works well when there are three or fewer stakeholders (typically the developer, director of marketing, and the CEO).
Once your company grows to the point where more than a handful of people are involved in the definition and development of a product, code-and-fix development leads to costly communication problems and produces a product that ships two months late with a user interface that only the developer can navigate.
Transitioning out of a code-and-fix development process, however, can be difficult. The stakeholders are typically attached to the flexibility that the style provides and are not thrilled about the prospects of adding “bureaucracy” to the process. You may also find that the management team has grown fond of talking shop with developers and then casually dropping newly acquired tech buzzwords between rounds of golf with fellow M.B.A. buddies.
To make this transition effectively, you should focus your efforts on developing clear lines of communication among all the parties involved. This will create the level of trust that is necessary as you start to expand the development process.
Here are some initial steps to consider as you develop clear lines of communication around your development process.
- Identify the Stakeholders
A stakeholder is anyone in the organization who is affected by the product or has an opinion about how it should be built. In a small company, this could easily be the entire staff. As the product manager, you have the responsibility to ensure that all stakeholders are up to date and that they understand their individual responsibilities regarding the development of the product. This can usually be covered by broadcasting minutes from your weekly core product team meeting and by regular, informal one-on-one chats.
- Create a Core Product Team
The core product team should consist of anyone who spends at least a quarter of his or her week working on the product. Typically, the team consists of a handful of tech folks (application, database, and QA engineers), a user interface designer, a marketing manager, a member of the sales team, and a customer service representative. This mix should give you a well-rounded set of perspectives (and fashion styles) to keep the meetings interesting.
To be effective, a product team must be empowered to make decisions about the feature set. The draft of the initial feature set and any changes should be defined and approved by the team. This creates enough of a barrier to ensure that changes to the feature set and to the schedule are well thought out. It also increases buy-in from the people who are most affected by the changes, preventing morale problems.
During the definition phase of a project, your core team may need to meet daily to work through all the requirements and tradeoffs. Once development starts, you should be able to meet weekly for less than an hour. These shorter meetings can be used to check on the schedule, discuss changes, and examine problems as they arise.
- Manage Management
Most management teams think that the product team is the cause when a launch date slips. The product team can cause a late product launch by creating an unrealistic schedule, writing buggy code, not defining the product well from the start, etc., but this has accounted for roughly 25 percent of slipped dates that I have witnessed. The other 75 percent of slipped dates are caused by a management team that sets the launch date without getting input from the product team or changes the objective of the product midstream.
It is hard to combat this problem, especially in a small company, but you can start to address it by actively incorporating the management team into the process. If your company is small enough, have your product team give presentations to the executive team regularly, sharing features, the current status, and problems as the product evolves. Since management teams typically have the attention span and reading skills of third-graders, be sure to keep your presentation short and visual (for example, by using graphs, mockups, etc.).
- Make Time for a Postmortem
A postmortem is a meeting of the core product team after the product launch. In this meeting, the group reflects on the development process, identifying what worked and opportunities for improving future projects. Effective processes are organic and unique to an organization. The insight that you get from talking openly as a team about the successes and failures of your existing process are infinitely more helpful than academic articles (like the one you just finished reading).
