There are many product development methodologies, each with their own strengths, weaknesses, and unique characteristics. Choosing a perfect methodology for your organization is impossible. While an existing methodology will be useful to start with, over time it should evolve and change as the company does.
Here is a product development life cycle that has worked well for me, and some big ideas for each phase.
When developing a product, the most important thing is figuring out how to deliver value to your customer. Having conversations with key stakeholders is paramount in the planning process. Typically, your customer is going to be the most important stakeholder. However, before you have customers, you might want to find an industry expert of your target market to plan around.
In the planning phase, it’s great to talk about what you’re doing (or not doing), delivering, who’s impacted, and timeline. Product functional specifications are perfect for this. Making changes to a plan is much easier than making changes to something that’s halfway done. While you’ll never know exactly what will change in the future, you can save a lot of time and headache by doing as much pre-planning as you can. Be sure to include engineers in the planning process, as well. You may be able to swap out a detail that is more difficult from a technical perspective, to something that is less complex with a shorter timeline.
Traditionally, development and QA could be two separate teams. In the startup world, your engineers might also be doing QA, or you’ll have limited QA people that also have another responsibility (engineering, support, etc).
The development process can be hard to estimate - especially for an entirely new feature, or something with a heavy R&D component. It’s a good practice to determine milestones, such as: Phase 1 Functionally Complete, or Phase 1 UI Complete. By splitting up the new product or feature into milestones, you’ll be able to accurately track progress. Time is always hard to estimate, but if it is known what has been done and what is left to do, it’s easier to see a path forward.
While we all want to “move fast and break things”, remember to write tests and think about long-term maintainability in development. Be aware of technical debt, but don’t let it hold you back. Find a balance somewhere between “sloppy” and “perfect”. Code reviews will help with long term maintainability and can catch issues before production, reducing the overall time cost in the future. Security and performance should also be built into the development process.
A beta period with the customers (and maybe a few more) that were involved in planning can be helpful at this point. Customers will be excited to have an exclusive preview that is centered around their experience, while your team gets the chance to iron out any last minute issues before general release.
Depending on what stage your company is in, the launch phase can either be extremely quick and dirty, or very thorough and calculated.
Launching is not only about the customer. Your own team is an important stakeholder in the process, so don’t leave them out! Make sure to prep your internal team about what’s coming, so they can make sure to add value in the process.
- Marketing can prime your target audience with industry-specific, provider-agnostic content, weeks before actual launch.
- Sales reps can reach out to prospects that were looking for that new feature.
- Customer success needs to know how to answer support questions, and can also do some upsells to current customers that were waiting for launch.
- Engineers (along with customer success) can help write Knowledge Base or How-To articles if your audience is more technical.
Your customer size (small biz, mid-market, enterprise) will also dictate how fast you can move. Enterprise companies will probably want a more fleshed out launch, with great documentation or webinars, while a startup-sized customer may only be concerned with functionality.
After launching your new feature or product, you’ll enter the maintenance and support phase. There inevitably will be some bugs at launch, but those typically will get resolved quickly, since everything is still relatively top of mind.
Bugs that break functionality are urgent, but other things like UI improvements or non-severe bugs should be put into the backlog for prioritization. Don’t forget to add anything to the backlog that you’ve incurred as technical debt.
Maintenance and support is ongoing. However, at some point, you may decide to sunset a feature if the cost or complexity of support outweighs the usage. It may also happen if your product heads in a different direction. Make a plan to inform your users of the decision to sunset the feature, as well as a transition plan. For important customers, it might be best to manage the transition for them, to minimize the impact to their day-to-day.
The product development life cycle can, and should, be adjusted to meet the style of your company and your customer. Understanding the needs of your stakeholders, keeping your team informed, and developing a flow within the process can all serve to boost your company’s growth.