Startup Software Product Development

Written by Liam McLennan

Software product development in new businesses is usually limited by a lack of funds and an excess of potential features. There is too much to do, and not enough time or money to do it. A startup needs to make product investment decisions carefully. Some mistakes are likely, but too many false starts can cause the enterprise to fail.

Many, if not most, technology startups seem to fall into the trap of HiPPO (Highest Paid Person’s Opinion) decision making. That is, they choose to invest based on the “gut feel” or “instinct” of the CEO. The problem with intuition is that it is frequently wrong. We can, and should, do better.

A Process For Software Product Development

As the CTO of a startup I have thought a lot about how to maximise our success in the face of much uncertainty. Being able to do a few things well requires that we say no to many opportunities. To guide this decision making we have established a product development process described below.

The first and most important step is to discover, clarify and consolidate the enterprise’s goals into a small number of clear goals that everyone can be aware of, remember and understand. Getting to these goals is more difficult than one might think. I have previously written about The Goal Tree technique for uncovering goals. At times leaders seem unsure about the wisdom of publishing their goals, and sometimes even embarrassed about them. For example, CEOs sometimes feel like they need to be seen to have a lofty change-the-world type goal and may be reluctant to admit the profit motive as a top-level goal. Nothing else described in the post has any value if the goals are wrong, so take the time to ensure that the goals are correctly identified, documented and agreed.

Once the goals have been agreed we need a process for evaluating, prioritising and scheduling initiatives.

1. Socialize and Propose

Good ideas can come from anywhere. Those close to the customers, for example, can often identify opportunities that the engineering team are not aware of. Our process starts with socializing the initiative with stakeholders, then preparing a proposal. The amount of effort invested in the proposal is proportionate to the size and risk of the opportunity. The proposal:

  • establishes a clear link between the initiative and the business goals that it will affect.
  • identifies quantitative goals for the initiative itself. Exactly how will we know if this initiative has been successful? If the outcome of an initiative cannot be measured, then leaders should be deeply sceptical. The goals section is the most important part of the proposal and the primary input to the delivery process.
  • documents research and findings
  • documents assumptions
  • documents risk and mitigations
  • describes the problem being addressed
  • describes the solution
  • establishes the items in scope and the items out of scope
  • estimates the value of the initiative to the enterprise. Work will not proceed if the effort estimated to be required is not significantly less than the estimated value to the enterprise.

Note that the proposal intentionally stays away from documenting solutions. The important information to capture is what we want to achieve (goals) and what is it worth to us.

2. Evaluate

Negotiate an implementation budget. If the initiative is worth $X how much do we want to invest in an initial implementation? As described in Basecamp’s process we try to find a solution that can be completed in 4-8 weeks, with some flexibility to change the team size so we stay in this window.

4. Scheduling

Evaluated proposals are prioritized. This prioritization must be done collaboratively and must be communicated widely. We use a large wall in our office.

Prioritization wall

Each documented initiative is represented by a card. The cards are sorted according to priority. When someone inevitably asks for all things to be done immediately we go stand in front of the wall the put the cards in the right order. This is a hard process, but essential! Sensible project management means confronting reality and choosing the best path with what we have.

The highest priority proposals get a team allocated and a schedule (start and end date). One member of the team is given responsibility for the overall successful delivery of the initiative.

5. Kickoff

This whole process is intended to maximize effective communication and one important activity is the kickoff meeting. The kickoff meeting:

  • ensures all stakeholders have a consistent understanding of what will be done and why
  • clarifies roles and decision making responsibilities
  • clarifies the schedule
  • recaps the proposal (goals, risks etc)

6. Design and implementation

Initiative teams are cross-functional including designers and developers (and any other skillsets required for the initiative). Together they must plan a solution that will achieve the agreed goals comfortably within the agreed effort budget. Neither design nor development may be overly ambitions in their planning without risking the success of the initiative, so there is a negotiation. This way we guarantee that the cost of the initiative is matched to its anticipated benefit.

7. Assess

Finally, the initiative is delivered, and its outcome measured. We return to the original proposal and record the measured outcomes against what was planned. Either way, we then have a choice to continue investing in the initiative or to move investment elsewhere based on the latest information. Thus, the process starts again from the beginning.

Further Reading