One of the things that I like to see in product development process is the establishment of product principles. If you have a formal product requirements document or whether your technical specifications include this type of information, I really find it useful to have a strong principle point of view at the start of the project. I often find that its a fantastic way to keep both the business and technical teams honest.
I always likened it to hypothesis testing in market research. You state an opinion that is either proved or disproved once you look at your data. I am always surprised when you have to re-read
your principles in order to reflect on whether you are building things to the objective of the project or not.
Having a list of 10-15 principles that are important to a product or project are extremely useful. What typically happens is that new feedback is introduced into the process from outside forces (customer feedback, competitive insight, etc) and you are forced to address your core principles. Or you are subject to the internal pressures where new functionality is being introduce (aka feature creep). The principles act as a statement of truth. They can certainly be changed but the leaders on the project should introduce a formal product review if a change is required since the business owner and technical leads should have already signed off on the project.
So, what should be in the list?
- Accuracy - how accurate is too much or too little? How can this be measured and what does the market need or how much will it bear?
- Performance - how fast is fast? Do you have a speed capability that is important to exploit versus your competition? Is there an ROI return for performance for your competitors?
- Business model - are there aspects to your business that make you have a unnatural competitive advantage versus your competition? Are there aspects to your business that make your customers more efficient or deliver dollars?
- Breadth - are there benefits to having your product everywhere meaning supporting lots of different types of systems or do you have significant market share that you can exploit? My favorite example is how Larry Ellison back in the golden age of the industry highlighted "open systems" as key differentiator for his Oracle software versus the proprietary (yet market leader) DB2.
- Scale - are there specific things that you need to develop that requires to process, stream. display or whatever across vast scale? If so, be specific and be able to explain what are the specific metrics for the scale that you are trying to achieve?
- Stability - we all know about this issue from the consistent downtime with Twitter. It is clearly not super important with that company. But, a B2B company is a different matter - downtime means loss of revenue.
There are a bunch of other things that could go on the list. I loved economics in college and one of my professors use to say, "the first thing you do with an economist is to kick <him> in the assumptions." Your principles are you statement of truth. Be thoughtful about them and be specific. Go ahead and kick your product in the assumptions.
Comments