Office of the Flywheel

I've worked in many industries, but in each of them there has been a need to develop Web based technology in one capacity or another. Even where the core purpose of the business has nothing to do with the Web, creating marketing, e-Commerce, client support, and sales support is a need.

Suppose you were to walk into an architectural office. You would expect to see people drafting building plans that detail everything from the floor plan, to the foundation, to plumbing and electrical, and so on. In fact, you would expect a great number of drawings should be required in order to build a building properly. And as you might expect, there is a whole discipline around the development of these documents.

Think for a moment about what your business creates. Here is a fun project for you. Ask around and see if you have documentation that thoroughly details the core of what you create. If you are in a Bio-Med organization I'm sure there are all sorts of documents, from chemical recipes, to device schematics, to case studies and trials, to patent applications, etc., etc...

But the creation of all this documentation takes discipline. It takes a type of person who is skilled at pulling vague ideas and concepts out of other experts, knowing enough about it themselves to be able to understand the ideas, and the ability to put it into a document that captures all of the essential details.

Not surprisingly, the businesses I've worked in have not had this dicipline. It isn't surprising, because I would speculate that adding this type of person to their team was the part of the reason they hired me.

Think of this discipline as a trial run. If you create a document that can be reviewed by subject matter experts and stakeholders, you can identify issues and find compromises BEFORE you invest in development. On this alone, the costs associated with the discipline - both in salary and in time - repay themselves.

I've worked in organizations where projects run by my colleagues flounder as they struggle with one release after another, not meeting the business requirements, or missing the feature expectations, or learning of issues late in the game. And I wonder why they didn't begin with a good set of plans. It is a classic and all too familiar lack of discipline.

Working in software - especially in Web/SaaS applications - Agile development is a new buzz word. I'm a fan of the SCRUM methodology myself, and have used it or variations of it on many projects, serving simultaneously as Product Manager and Scrum Master.

Part of the Agile process is the creation of User Stories. I really like user stories, because the methodically walk through the most important use cases for an application. And in the project management of Agile, these User Stories are written down - usually in an PjM application and get associated to an Iteration in the Iteration Planning Meeting.

Taking this one step further, another branch of thought in Agile is Extreme Programing. In my experience you create almost no documentation, leaving it up to the engineer uses their creative and intellegent mind to create the necessary code.

I've worked in companies founded by technologists, and the strategic direction was dictated by engineering. I've worked in companies where senior marketing executives were brought in, and the control came from their department.

I bring these methodologies and departmental scenarios up, because it really highlights the need for what I call a "Power Center" within the organization. In my opinion the best way to create a power center is to:
1. Make Product Management its own department
2. Make Product Management accountable to all of the other departments (it serves them)
3. Give Product Management the responsibility for delivering
4. Give Product Management the authority to execute
5. Require Product Management to define requirements in a format that is accessible to all departments

Several things happen when you do this...

Steps 1 & 2 put Product Management in a submissive role, where it is required as a key function to collect and document the requirements of these departments. Regardless of the departments you have in your organization, Product Management becomes the information hub between them. Connecting the needs of these departments results in a natural effort to negotiate inter-departmental synergies and compromises.

Step 3 forces Product Management to set priorities. When priorities favor one department over another this time, the exchange can be in trade the other way next time. Not that everyone will always get their way, but you have a servant department that becomes a common intermediary between areas of the organization.

Step 4 gives Product Management the autonomous ability to drive decisions and execution. But this is held in check by Step 3. So you don't create a department that acts as a dictator, but you also don't create a department that bends in the breeze. It is a check and balance system that ensures accountability.

Step 5 is the Rosetta Stone, the blue prints, the patent definitions, the magic. I've invested many years developing my particular style of information architecture and wire frames. These work amazingly well for software development. I can put them in front of a marketing person, a software developer, a graphic designer, and a sales person in a round table meeting and we can all talk about what it is, how it impacts our departments, and pen up collaborative solutions. Before I have a team write a line of code, I've turned a few revisions of my document and ended up with something I know will work, while maintaining the ability to adapt over time.

Possibly more important than any other part of my job, maintaining this discipline around product specifications is the most important. I will never be an expert in all things, but the documents created by myself and my team are informed by the gamut of experts. Therefore, the resulting specifications represent the group mind with the:
- Interdepartmental needs
- Interdepartmental prioritization
- Interdepartmental compromises
- Interdepartmental synergies

My motto is "the more people are involved, the better my specs will be." Of course you have to know how to get the right people involved, prevent getting too many cooks in the kitchen, and filter out noise related to in-fighting. But I've noticed that when you develop great specs, based on great group input, you deliver great results that benefit the whole team. When this happens, you build motivation to participate in your process. You help erode the internal conflicts. You help build overall momentum. And you help accelerate your organization on a path to building greatness - regardless of what business you are in.