20 Lessons From Introducing High Quality Software
Learn How To Manage & Ship A Great Software Product
Get 20 lessons about how Software CEOs can grow their team, improve their culture, and create efficient work processes on the way to building a massively successful Software Company.
Here are the main points summarized from our 4 recent articles on Introducing New Software.
- A software application is not inherently good or bad. It is measured only by its utility in solving a real problem for a real customer.
- Don’t fall in love with your software creation. That will lead you to defend it rather than stay open to changing and adapting it to users’ needs.
- Somebody somewhere is using something else to solve the same problems you’re trying to solve with your new-to-the-world application. It’s critical to find out what they’re using — what they like about it, shortcomings, frustrations, etc.
- Using multiple development teams has pros (different perspectives, challenging assumptions) and cons (unhealthy competition, coordination).
- When choosing development partners, it’s not just about the quality of their software, but more about their collaborative attitude, humility, willingness to put the project first and readiness, willingness and ability to jump in and identify and fix bugs and modify and adapt the software.
- Make representatives of several different target user communities part of your Development Advisory Group and involve them continuously throughout the process.
- Make sure people on the team know how to do what you are asking them to do. Sometimes people will just refuse to do something, and take the risk of seeming stubborn and arbitrary, rather than admit they don’t know how to do it. If they don’t know how, give them what they need to learn.
- Specs, coding and testing can and should be separate functions for accountability, but people should be loaned across lines to manage resources and to encourage a shared commitment to the whole project.
- Strike a balance between allowing coders to do their work undisturbed vs. letting them connect with real users in real time so they can see the expected benefit of what they are doing in the real world.
- “Late changes” are a natural part of the process, and should be expected and prepared for, rather than regarded as a threat to the process.
- Code should be written with respect for rapidly changing needs in the marketplace and user community. That means close coordination between user advisory groups, spec writers and coders and writing code smartly and in such a way as to leave key variables open as long as possible.
- It’s obvious you can’t have everything in the first release. Deciding exactly what will be in and what has to wait is a critical decision that should include input from everyone, including users.
- Don’t just listen to what prospective customers SAY they want it to do. Use rapid modeling tools to engage users in discussions leading to what that really LOOKs like.
Development is never finished, but significant milestones should be set and celebrated when accomplished. - Be realistic about delaying release dates. Sticking stubbornly to a date leads to poor quality, customer dissatisfaction and bad morale in your group.
- When possible, borrow from the scientific method when designing test plans: Vary one condition at a time, while holding others constant. It means a bigger test deck and more work, but it’s more likely to uncover more bugs more reliably.
The Right Process For Customer Acquisition And Retention
- Don’t start with an assumption that having ONE marketing plan will fit all customers. Assume each user is unique and help them, one-by-one, become customers. That means starting with a unique “marketing plan” for each user. Then group target customers into market segments that share characteristics, and have a marketing plan for each of those segments.
- It’s hard to get people to try new applications. Consider asking prospective customers/users to show you the real problem they’re working on with other tools so you can work on it alongside them and prove you can solve THEIR problem with YOUR software — faster, better, cheaper.
- Every prospect/customer/user counts. When someone says “I hate this software,” dig in to find out the specifics behind generalized user complaints.
Learn How To Manage & Ship A Great Software Product
Get 20 lessons about how Software CEOs can grow their team, improve their culture, and create efficient work processes on the way to building a massively successful Software Company.