Creating Product Development Principles
I previously described creating a brand-driven product vision, which is an invaluable guide for keeping your product inline with your brand idea. But a product vision is just that—a vision; something general.
For the 4040baseball project, it became apparent that we needed more than a vision to measure our coding and design patterns against. Especially, since we wanted our brand to permeate every level of our product.
Hello. I am your software. I represent you. You are powerless to stop me.
The 4040baseball product should be the personification of our brand. And I mean that in a very real way. In software, the product is the primary representative of your brand--it’s the first point of contact through which your clients will interact with your company. And since your brand is inexorably an extension of who you are, we thought we’d put in place a set of practical rules to remind us who we are and what we strive for.
4040baseball's PDP
What follows are the 4040baseball product development principals:
1) If a task does not add real value to our product, we won't do it. Questions we ask: Does this task clearly increase effectiveness? Does this task clearly increase simplicity? Does this task clearly increase ease-of-use? 2) Code loss is greatness! The more code we're rewriting, the greater the value-add we must have discovered. 3) Build for the now. We do not architect for future use until the future is upon us. In the agile world, priorities must change on a daily basis. We code for what we need today. We will convert today's code into reusable code at the moment when we know we need to reuse it. 4) Abstraction is not our friend. Our code must remain simple. We must never abstract our code beyond what we need right now. When abstracting code, remember our first principal, and keep it effective, simple and easy to use. 5) Our design patterns must be identifiable and predictable. When solving problems, we must repeat the use of established design patterns where possible. 6) Servers are finite, clients are infinite. For every 100 visitors there are an equal number of web browsers waiting to be put into service. Where possible, we will hand off processing responsibilities to the browser and use MVVM and ajax to lower demand on servers and bandwidth. 7) No shims or polyfills. We use HTML5, CSS3 and responsive design. We will not use custom code or frameworks to make our software compatible with older, lesser browsers. If it works with current Apple Safari, Google Chrome and Mozilla Firefox, our job is done. 8) Bugs are urgent, fixes are not. We will quickly get bug fixes in progress, but we will not rush their solutions. Quality and thoughtfulness are the only objectives of a bug fix. It's better to let one bug persist than to create an additional bug, or degrade user experience, on its heels. 9) Poor comments mean poor code. Comments must be thorough, but efficient. We should be able to read only the comments to understand the code.
Unique to each product
Product development principals are unique to each product. The list above works great for 4040baseball, but wouldn’t be so great for a lot of other products I work on.
You can see that our brand idea of simplicity and elegance has influenced the decisions we make as a development team. This is intentional. It stands to reason that all aspects of our software should point in the same direction of simple effectiveness. And, if you’re familiar with the Kano model, it further stands to reason that the quickest path to customer delight is a high-concentration of problem solving (innovation) and the least required amount of effort. Paramount to that success is a deliberate focus on adding value as efficiently as possible.
Summary
You can develop your own PDP by understanding your brand idea, using that to shape a product vision, and then asking yourself how to put that product vision into practice. Later, I’ll discuss realistic brand ideas.
