This is part 4 of a series of posts that examine how product quality is everyone’s responsibility. For reference, the previous posts included:
- Part 1: Sales and Development
- Part 2: Consulting and Support
- Part 3: Marketing and User Experience
In part 4 I’ll explain how your PM and Leadership teams own the quality of your product/service.
The PM Team
Because there are multiple definitions in the tech industry about what a “PM” does I’ll simplify that this is the person closest to the engineering team. If you are on the PM team you approve requirements, build specs (tickets/user stories/whatever you want to call the definition of work), work as the bridge between disciplines, manage the schedule progress, and work with customers on direct feedback. If this describes you how do you own quality?
- Prevent scope creep. If a requirement is to solve problem A… but it’s only “1 week more to also solve problem B”… even you believe the cost… does solving B really matter or will no one care? And never believe that additional cost.
- Eliminate options. Nothing kills the long term stability and usability of a product faster than the phrase “What we need is an option for…”. Options should be the last resort. At best they something you have to explain to customers and they are most likely a failure waiting to happen because of the following equation: Option = increased code complexity + increased test matrix requirements. This means you’ll occasionally pick something that 10% of your customers don’t want… but the other 90% will be much happier.
- Reduce dependencies that introduce points of failure into the system. Understand how something is being built, what libraries your developers are using, what the added customer requirements are, and what 3rd party services each work item depends on. All of these things are points of failure you may be introducing into your product.
- Define success. It doesn’t matter if your company uses waterfall or agile methodologies. At some point, someone, somewhere defines what success means for a chunk of work. Vague definitions = vague results and confused users.
- Be your own QA team. You can’t rely on the QA team to validate the customer experience of the work you owned. This is up to you. Some things look great on paper but just don’t integrate well with the rest of the user experience. You own the sign off of your feature and “It was built to spec” shouldn’t cover it. “Am I proud of how this solves the problem?” is closer. I always found that recording demos for other team members always uncovered these flaws the quickest.
- Talk to more customers. Don’t make them up.
A pessimistic way of looking at your PM team is that these are the people that should be experts at saying no. A better way to look at it is that they are orchestrating the delivery of the most elegant simple solutions to business problems and customer need. They deliver bang for the buck.
Leadership
I’ll define this as simply the people in charge and responsible for the strategy, direction, and budget for the product. There is no one MORE important than you when it comes to making a quality product in the following ways:
- Focus the strategy around specific, real, customers and communicate that strategy frequently. Each release should have a sub-strategy and set of target customers behind it. Who should be elated with your products next release and why? Everyone will have lots of good ideas about what “needs” to be in a release, but it’s your job to make the right bets and tell most of them no. Demand strong customer validation of the big ideas from real customers that mirror your ideal.
- Understand the famous triangle of scope, quality, and time and realize that each dimension impacts the others… except that it’s worse than that…
- The larger you make the whole triangle the less connected employees will feel to the release. Big releases are dead. Unless you are Apple, Google, Facebook, or Microsoft you need to understand there is no such thing as a “big release”. There are simply releases. Making them bigger only increases risk and creates a bigger divide from the work and your biggest motivational tool… demonstrating satisfied customers. Let the “big” guys have the customers that only want updates every three years. Releasing frequently is your advantage over the big guys.
- Set a high quality/experience bar and demonstrate that bar by giving feedback frequently during development. Ultimately it’s your name going on the whole package so you have to show people what it takes to make YOU proud of something. Make it clear to your managers that people that aren’t consistently producing work you’d be proud of should find other employment.
- Make customers the focus… for better or worth everyone should have a transparent view into the good and bad feedback you receive as well as your take on that feedback… make sure you send feedback that overlaps the customers expectation with your goals for the company… these are nuggets that should be amplified.
- Create the right environment for your strategy. I believe that a persons environment has a lot to do with the outcome of their work. For example: Social products need a happy/social environment and transparent social process This goes all the way down to the tools and process people use. If you are going for “simple” in your UX then you should force the team to use simple tools and process for tracking bugs, features, collaborating, etc. If you spend half of your day looking at a tracking tool that’s complex and demands too much information then the bar has been set for simple in your environment.
I’ll wrap up this series with a look at what the QA team does to own quality. Feedback is always welcome.