HPMD Bullet: Product Management Proverbs

HPMD Bullets

BULLET #7
PRODUCT MANAGEMENT PROVERBS

The reality of the 90's is that in order to compete you must be fast and accurate in all aspects of your business. Software product management is not exempt. The following are a collection of insights -- proverbs if you will -- about the business of developing quality software products faster than traditional development cycles. While many have been honed from past experience, some are newer ideas to be tried and tested.

1. Build for the identified market need, with features that will specifically increase revenues.

2. Make the customer part of the design and development team at the outset to "get it right" from the start and eliminate the need for long beta tests and redesign.

3. Build paper models, or black-box prototypes first, to get user confirmation before any code is written.

4. Use one designer, or "chief surgeon," as architect of the system, to ensure continuity of design and quality. But get a second opinion before the procedure begins to avoid any tunnel vision.

5. The prototype, or initial system, becomes the specification; specs don't come first. But they must come.

6. Build reusable software components and tools so that each application reinvents the wheel less.

7. Document, distribute, and teach the tools approach to all developers. And expect all to use them.

8. Decide the interface standards up-front to avoid "uniqueness" of operating each application.

9. Avoid the "not-invented-here" syndrome, especially for using common tools and modules, and for using a common user interface.

10. Have developers make verbal contracts in advance, to complete a project within the time frame. Tracy Kidder calls this the process of "signing up" for the project.

11. All parties must commit to due dates and honor them as a matter of professional pride.

12. Assign all tasks and sub-tasks for the entire development and release cycle, with clear responsibility, so it's obvious who owns what.

13. The only shared responsibility is getting the product done and done well.

14. Developers should do their own testing. The QA department merely confirms.

15. Build diagnostics into the product.

16. The customer is not the QA department.

17. Feature freeze, or the point at which all required features has been added to the system, is the mid-point of the development cycle, not the end-point.

18. Documentation, QA, customer service, billing, sales, marketing, and any other impacted department ought to be part of the development review process from the outset.

19. Celebrate and praise good code.

HPMD