When it comes to product development, there is no recipe or framework to ensure success as
the qualifications for success will vary from project to project. For example, maybe the goal behind a product isn't to make money, but to explore a market. In that scenario, success means quick and cheap product to market, regardless of acceptance. Luckily, there are common ingredients, or essentials, that apply to product development, whatever the purpose. I touch upon 10 essentials that have come up time and again in my career, and are central to successful product development.
Establish a Minimum Viable Product Before Developing
A Minimum Viable Product, in my own words, is the minimal amount of value needed for a product to enter a market. It sounds product centric, however, an MVP is actually risk centric with focuses on items such as initial capital, return of investment and market acceptance. An MVP is about the affordance necessary to get the proverbial foot in the door and only then will it be clear which direction to take the product. Can the product build roots where it is? Or perhaps, a pivot to a different market will become evident once it is deployed. Establish an MVP (usually in the form of requirements) before establishing the software development team (if you want to save lots of money). For that dev team, the MVP should drive many questions and decisions:
- Is commercial, 'off the shelf' software, already available for leverage, or, is a custom software solution to distinguish the MVP in the market place the right decision?
- Should we invest in costly software development tools, or develop with free and open source software?
- Are we setup to be Agile? Meaning, do we have some effective and corrective feedback loop to respond to growing pains along the way?
Create Project and Product Owner Roles
These are perhaps the most crucial roles to success. The project owner knows the market, and the value that the product will provide. He/she is key to ensuring the product maintains alignment with business objectives, and shares this alignment map with the team. Project owners know how and when to pivot, if necessary. The product owner, on the other hand, knows everything there is to know about the product. When the dev team has questions, these two roles provide unequivocal answers. These roles behave nearly unilaterally (after approval from management). This unilateral and unequivocal nature allows for efficiency. It saves hours, days, weeks, possibly even months of an otherwise lengthy and indecisive democratic process while costly development teams await direction.
Ensure Dedicated Roles
Ideally, each role should be dedicated. Context switching is one inefficient and well documented reason against giving a person multiple roles. If a product owner serves many roles, especially higher priority roles, the fidelity of the product will suffer. If a developer also has a technical writing (documenting) role, integrity of the product will suffer. Not to mention, you will be overpaying a developer to write documentation while decreasing progress of the product. Still, the most surefire way to fail a project is to two-time staff between their day-to-day jobs (of which they will place higher priority) and a development project.
Get Independent Estimates
It's worth assessing whether or not you will even be able to afford your MVP. Avoid relying solely on estimates from your internal, or consultant, software development team. Consider getting a software estimate from an experienced company who has a one-time job of estimating the MVP to market accurately and has no other stake in the product, development or otherwise.
Have At Least One In-House Software Representative
If you are contracting for your project, have at least one experienced software role who can participate in the project. This role serves to represent the company for many potential situations. If a contractor is put on hold, this role can continue operations, albeit at a slower pace. This role can maintain the software, and keep knowledge in-house when the contract period is up. Most importantly, this in-house role helps provide checks and balances between the contractor and client, such as ensuring that best practices like peer reviews and testing are followed.
Keep Your Team Productive
Inspect and adapt. This goes for process, tools, staff, environment, anything. Ensure there is an open line of communication for anything. If a problem is raised, the entire team should be poised to adapt quickly. Keep what works, and throw away what doesn't. If Instant Messenger software crashes frequently, replace it. If 50% of the people aren't necessary for a 2 hour meeting, don't invite them. If your team knows what they need, and are frequently waiting for approval, consider giving the team authority and allow them to self-organize. This autonomy allows teams to effectively evolve into a custom solution where obstacles are removed quickly and more time and money is spent on the product.
Keep Your Team Happy
An unhappy team produces unpredictable results. There are three major ways to produce unhappy teams. The first is to retaliate against them by ignoring, marginalizing, or ridiculing what they have to say. The second is when they don't have the resources or means to get the job done effectively (per productivity, above). The third, and most common is to burn them out by running them at 100% utilization. When teams are at 100% utilization, they have no room to process anything new. There is no time to deal with emergent issues and ultimately, there is no time to reflect or innovate which are cornerstones of both personal and business growth.
Use acronyms like INVEST or SMART to ensure each unit of work is manageable and moving. Keep your eye on solving the problem, not the solution selected to solve it. This year's solution can be replaced by next year's, but the problem remains the same. Beware of dogmatism - the belief that there is only one way to do something. Hold conversations where competence and experience, not just book knowledge, prevail. Remember that "perfect is the enemy of the good." Teams can easily get wrapped around the axle for hours or even days on a feature that isn't even part of the MVP. Nipping that in the bud translates to getting the product out the door faster.
Follow Development Best Practices
Best practices don't say what test methodology to follow, for example, they just say "Test". It's up to the team to pick one or many approaches, and to what extent is appropriate. That said, ensure that the product quality is all it can be by following best development practices. This includes version control, peer review, testing, refactoring, and iterative development (i.e. setting up production from day one and incrementally adding to it until the MVP is complete). This sounds like a task for just the development team, but it is management that must ensure that considerate time and resources are allocated for these very important practices.
Focus on the Product
Project manager roles exist to remove impediments to progress. It is sometimes ironic then, how the progress of the product is hampered by management. With good intention, management frequently wants insight into progress. This, if done incorrectly, can actually introduce impediments. Worse, management may want to pressure the team to deliver more or sooner, which will have the opposite effect. The objective here is product success, not project success. Find ways to get metrics on product progress without being intrusive to the team delivering it.
Perhaps the most important aspect to success, which can't be distilled into any article or book, is the quality and competence of your team members. However, with a quality team in place, this list is a great start to ensuring success for your new or existing product development.