Which is more important to first get right: Effectiveness or efficiency? Intuitively many choose first to be effective: Just get it done, worry about doing it properly later. This approach may produce short term gain but it is disastrous in the long run. Even though some things may get done, doing them inefficiently takes away from the enjoyment of our work, depletes our energy and momentum, and causes ineffectiveness; this is true for individuals as well as teams.

Yet a principal responsibility of managers—shareholder proxies—is to ensure the long term sustainability of the businesses entrusted to our care. We give ourselves every chance of success when we focus on efficiency first, and then effectiveness. Form before function. Quality before quantity. How before what. Efficiency results from following the correct form. Effectiveness produces an intended result.

This introduces a dilemma many of us face: What is the intended result—the function or purpose—of our efforts? It’s not enough to be effective; we must be functional, or purposeful, in what we do. In applying our efforts efficiently we need to strive for the vision we are intended to serve.

In getting to grips with your purpose you should analyze your answer to this question, “For whom or for what am I here?” It may be interesting to hear your team respond to this as a gauge of how plugged in they are to your corporate and product vision.

Why is it important to master these fundamentals? Because you can waste a lot of time by being effective but not efficient—getting there at any cost; by being efficient but not effective—efficiently doing the wrong thing; and, by being effective but not functional—self-service, for example.

Adding value is about being both efficient and functionally effective. As an agile manager you need to drive from vision to form to function to fulfillment, both for you and the people you oversee. You’ll save a lot of time and regain the enjoyment and satisfaction you used to get out of software development.

In my opinion much of what we read and see about Scrum is to do with efficiency. This is fine, but I think it is time for many organizations to start looking at being functionally effective as well.

Many voices
As I gain more experience I’m realizing that holding fundamental views will probably lead to marginalization. It’s difficult to get things done on the margin. I find it’s better—more effective in the long run—to seek a balance. I think that is why product ownership, through the role of product owner, is so interesting to me, and holds so much potential to help get things done effectively, quickly, and inexpensively.

By way of background, it is quite common for there to be disconnected relationships between business, the market, and software development in companies today: Whilst business interests are usually expressed in commercial terms, software or technical interests are expressed as a desire to produce the right solution. Market interests are usually expressed in economic terms, and the need of users to do a job or perform a task.

These different interests may also be brought to bear in unequal strength. This disconnectedness, especially when applied to external parties such as the market and some stakeholders, often leads to mismatched expectations and disappointment.

The solution lies in business, the market, and software production working together through the role of product owner. Through the product owner priorities are set based on the business goals and user needs for each incremental delivery of software. And these priorities are moderated against the realities of software production and maintenance by considering aspects of feasibility, resource capacity, and complexity.

Product ownership is the key to balanced relationships between stakeholders, the market, and software production. Although these relationships may be desirably stressed, they are nonetheless held in balance by the product owner.

A product owner achieves this by directing the software development team to deliver the right solution to market that meets user needs and stakeholder expectations, in a way that is innovative, ethical, and respectful of the rights of others. Product owners carry out their duties with a relationship focus.

The right solution meets user needs, and here is it always important to remember that users use the solution in the context of their business process, in other words to do their jobs or perform a particular task. The right solution also achieves stakeholder objectives, which are usually, but not always, expressed in currency.

Tom Peters was recently quoted as saying: “It’s always ‘the people’. […] Network, keep your promises, behave decently. You are as good as your relationships. […]” Although this is generally true in life, it is also particularly true of the relationships between product owners and stakeholders, users, and the team.

Product owner relationship with stakeholders
What kind of product owner responsibilities can be discharged through good working relationships between them and stakeholders?

1. Identify, aggregate and prioritize stakeholder commercial objectives and expectations.
2. Play a leadership role in determining product strategy and direction.
3. Influence or negotiate key strategy decision points and milestones.
4. Identify, establish and maintain strategic relationships with key internal and external decision-makers and stakeholders.
5. Form and maintain the product vision.
6. Identify, contract, and maintain business relationships that defend the product against strategic threats, create defensible competitive advantages, profitably grow existing business, and exploit or create new market opportunities.
7. Develop innovative product recommendations based on commercial, technical, and legal assessments.
8. Develop and maintain business cases.
9. Identify and drive corporate themes through the product.

(A point about these responsibilities: My view is that they themselves should be treated with agility: In other words, they should be met in the context of the product, the business, and the other roles in the organization, like Product Managers for example.)

How do product owners sense they are moving towards their objective of meeting stakeholder expectations? Spend time with them. Apart from day-to-day interactions with stakeholders I usually encourage product owners to host regular sessions with them in order to articulate key business risks and opportunities.

But having something sensible to say to busy executives who have committed their valuable time means that beforehand product owners should have mapped their products’ ‘DNA’ to provide a framework to discuss current and future product initiatives. It may prove handy to refer to a conceptual model, and a trading community model, during these sessions as well.

In my opinion nothing creates a visceral connection between product owners and their products like a business case and vision. Although products owners groan when I say they should write and maintain these artifacts, they are not the 100-page tomes of the past.

Mark Twain once apologized to his readers: “I didn’t have time to write a short letter, so I wrote a long one instead.” This shouldn’t be the approach product owners take with these documents: 3 pages each for a business case and a vision. The outcome of the stakeholder sessions should be that the content of these documents is confirmed and updated.

Also I’ve found that distilling out the product vision into a goal model is a very useful exercise.

Product owner relationship with the team
The next key relationship product owners need to maintain is with the team. And although their relationships with stakeholders and the market are vital in determining what gets built next, it is in the context of the relationship between product owners and the team that the work actually gets done.

The responsibilities a product owner discharges through this relationship are:

1. Direct production to meet stakeholder expectations and user needs.
2. Share the product vision with the team.
3. Identify, aggregate and prioritize features and related benefits the product will deliver to users.
4. Prepare and maintain a prioritized list of summarized and detailed work items.
5. Describe product functionality by way of user stories.
6. Negotiate to prioritize work that mitigates technical and financial risk.
7. Prioritize work that accelerates team learning.
8. Validate the product for release, including use of user testing.
9. Decide whether to ship the product.

Finding the right balance between documenting and doing is an art that still causes some anxiety in the team. And clearly not all documentation is bad. I encourage product owners to use the business case and vision to create a data sheet, which can be used to articulate the broad product vision to the team on a continuing basis.

This document distills out of the vision the principal features of the product, and their related benefits, in user language. If software was still sold off-the-shelf, this would be the promotional material printed on the outside of the box.
The overview is another document I encourage product owners to produce. This artifact contains as many of the product’s features and related benefits that have been conceived at this point, in more detail than the data sheet, but still in user language.

The overview, like the data sheet, still honors the product vision. Because it communicates how the product owner has interpreted the vision, when reading the overview team members often say, “Oh, I didn’t know you meant that. We’ll have to have a conversation about it.”

Then if proposed features and benefits need to be discounted for any reason, everyone is aware of the base off of which this is being done.

Obviously sprint planning sessions, sprints, and sprint reviews are opportunities to cement good working relationships with every member of the team. The strength of these relationships will shine through in the product. Keeping the team pointed in the right direction is facilitated through strong product owner leadership of the product backlog.

With the previous documents in place the product backlog, which is a prioritized list of tasks described as user stories, becomes a doddle to produce.

Product owner relationship with the market
Following on from the relationship with the team, the last key relationship product owners have is with the market. What kind of responsibilities rest on product owners with regard to their product’s market?

1. Identify, aggregate, prioritize user needs.
2. Study and assess new markets, applications, products, and partners.
3. Perform gap analyses.
4. Follow commercial, technological, and legal trends.
5. Develop and maintain access to customer and industry evangelists.
6. Produce innovative, needs-based solutions.
7. Possess a strong understanding of customers’ issues and priorities.
8. Champion the product to internal and external audiences.
9. Study the product domain.

One of the benefits Agile offers is greater transparency, although too often this is only felt inwardly – inside the organization.

I like to encourage product owners and their management to become comfortable publishing a product road map externally, to customers. This document creates an effective way for the market – as well as internal stakeholders – to view and interact with the product development pipeline.

On this basis, informed and unemotional discussion can be had about priority before inappropriate choices develop into crises.

In my experience, the benefits arising from your market being settled in the knowledge that you have a strategic direction for the product, for which they can plan, often results in greater customer loyalty.

How versus why
Does Agile mean an end to all documentation? To those looking at adopting Agile practices, especially if they come from more traditional project management backgrounds, Agile can seem quite loose, especially in the area of documentation.
The Agile Manifesto values working software over comprehensive documentation. And in agile projects working software is perhaps the ultimate quantification of your project’s status. This may take some getting used to.

It’s perhaps obvious that the signatories to the Agile Manifesto are not saying that technical documentation doesn’t have any value. No—they’re simply emphasizing the value of working software over comprehensive documentation. They’re saying that as working software should be the team’s goal, if producing detailed documentation for tradition’s sake is getting in the way of this, then it is time to adjust how much paperwork is produced.

In addition, there are a number of the principles behind the Manifesto that elaborate on this value: Working software is the primary measure of progress; [The team's] highest priority is to satisfy the customer through early and continuous delivery of valuable software; deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale; and, the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Sometimes end-user documentation is used as a criterion for ‘Done’. Sometimes it’s used to document decisions for team continuity. And documentation may even be needed for regulatory compliance.

With regard to how much documentation is produced I’ve found it’s OK to leave the team to answer two simple questions: Is the documentation valuable? Is the team better off for writing it?

In my view this Manifesto value really addresses aspects of the project’s efficiency: The ‘how’ of the technicalities. The product owner though, may be more interested in artifacts describing the project’s functional effectiveness: The ‘why’ of the business. This is because I think product owners are responsible for the software beyond its manufacture: Why you invested in it, and why it complements your organization’s broader business plan.

I’ve had great success using product ownership documents to capture the business essence of an agile project. They convey stakeholder expectations of the project, the user needs the product will meet, and how the product will evolve once in the market. In my experience the benefits these artifacts bring to the team far outweigh the cost of producing them.

As mentioned previously I strongly encourage product owners to produce these documents because they connect very deeply with the product through this process. Then, when the hard product calls need to be made, product owners will find the answers within them. And their confident, consistent decisions will earn them the respect of the other team members. Stakeholders will feel safe in their hands, too.

Firstly there are pre-production documents, then those that face internally, and lastly the road map, which in my ideal world is an externally-facing document. Please be clear though, that these artifacts are a support for face-to-face communication, not a replacement for it.

Business case
In a nutshell, the business case is the economic plan for realizing the product vision. The purpose of the product business case is to set out: Stakeholder expectations; a mapping of the user needs to features to benefits; the proposed financial model; market opportunities identified; and, a product positioning statement.

Albert Einstein once said: “The formulation of a problem is often more essential than its solution.” I’m sure he wasn’t talking about a business case at the time, but it’s equally apt to apply it to this essential product tool.

Yet many business cases I’ve read are framed in the solution domain, which should cause concern because the business case may then propose solving the wrong problem. And because technology derives its value from the underlying business problem solved, solving the wrong problem will result in a sub-optimal return on investment.

Also, solving the wrong problem means the solution will most likely fail because it’s implemented in the wrong context.

Solving the correct problem begins with asking questions. Not knowing where or how to start is a common problem product owners face, and I find it helpful to remind them of a Rudyard Kipling poem in which he sets out a simple set of question framings:

Six Faithful Serving Men, by Rudyard Kipling
I have six faithful serving men
They taught me all I knew
Their names are What and Where and When
And Why and How and Who

Despite their protestations I always suggest product owners write the business case for their product. It sometimes takes a lot of convincing, but making the effort to argue for their product helps product owners tremendously when they need to make quick, consistent product calls.

Typing the first few words is often the most difficult, and maybe these fundamental questions may help them build their case: Why should stakeholders invest in the product and how will it translate into increased shareholder wealth? What is the problem or opportunity that needs to be solved? When did the problem start happening? Who has the problem? Why is the problem occurring?

These simple questions should give product owners a head start in producing compelling business cases for their products. Another good way to test how well a product owner has grasped the core problem is to gauge how compelling is their product positioning statement.

The standard form of positioning statement I suggest is this:

For [target market], who [compelling reason to buy], our product is [product category] that [key benefit], which unlike [main competitor], our product [key differentiation].

These days, when only remarkable counts, perhaps Kipling’s poem could be rephrased:

I have six faithful serving men
They taught me all I knew
Their names are What and Where and When
And Why and Wow and Who

How is not good enough anymore, it needs to be Wow! And Wow! begins its life in the business case.

Vision
The vision is the chance to describe what the perfect product would look like—the outer bounds of market and functionality. The vision is derived from the business case and illustrates the problems that must be solved to reach the product’s goals, yet it should not be constrained by what is technically possible for the team.

The product owner is a key role in ensuring the right product is built, by ensuring that everyone is focused on the real needs of the end user. They also ensure that the most valuable features are built first, and that low value features are never built at all. The product owner holds before the team a vision that will motivate them to commit to building a winning product.

Accelerate Cape Town’s Guy Lundy was recently quoted as saying, “A vision is a story people tell with their lives.” Everybody, everywhere, all the time. Each one of us becomes so gripped by something—a dream, ambition, fear, greed, drudgery, sufficiency, self-service, our leader’s enthusiasm—that we live it out in a way that speaks clearly to all who choose to listen.

Stop for a moment and listen to the story your life is telling. What story is your team telling? Does their story assure the stakeholders that they have caught their vision? It should, because they’ll build what they see.

Data sheet
This document distills out of the vision the principal features of the product, and their related benefits, in user language. If software was still sold off-the-shelf, this would be the promotional material printed on the outside of the box.

Overview
This artifact contains as many of the product’s features and related benefits that have been conceived at this point, in more detail than the data sheet, but still in user language. The overview, like the data sheet, still honors the product vision. As mentioned earlier, because it communicates how the product owner has interpreted the vision, when reading the overview team members often say, “Oh, I didn’t know you meant that. We’ll have to talk it through.”

Product backlog
With the previous documents in place the product backlog, which is a prioritized list of work items, or more commonly called user stories, is created by the product owner. Each story is a ‘promise to hold a conversation’ and from which the product owner, team and scrum master choose the deliverables for each sprint.
A user story is often framed in this way:

As a [user type], I need to be able to [feature description], which results in [benefit description]. (Mike Cohn)

Road map
And with the backlog in place, the road map is easy to produce. It is a release plan of future functionality and is often a quarterly snapshot of the product backlog in a form that could be presented to internal and external stakeholders. The road map is a communication vehicle, aligning internal and external stakeholders with the goals and priorities of the product at each stage of the plan.

It provides decision-making criteria for feature prioritization. It defines what success means for each release. It defines the main new features and components, and the basis for the functional specification, of each release.

The road map provides an objective reference as to how well the product team is performing according to its goals and acts as a tool for evaluating whether its assumptions and strategies have panned out, or if the product team should negotiate with stakeholders and the market to alter or switch strategies.

The road map may also illuminate other options and alternative strategies the product team may decide to adopt, again after negotiation. The adoption of a new option or strategy that deviates from the original business case and vision should be reflected in these documents. This outcome is quite uncommon.

Although some executives shy away from publishing the road map externally for fear of raising the market’s expectation of future functionality, I’ve found the benefits to outweigh the risks. The market appreciates that you have shared your plan for the product, and in turn it can participate more meaningfully in setting priorities.

Above all the road map tells both us and the market that we have a vision!

Co-ordination rather than planning
Where does a product owner fit in to an organization? Ideally, I think product owners should report into a Product Development executive, otherwise into Business. I have found that product owners reporting into Production really doesn’t work well.

If your organization has a Product Management function, aspects to do with the product’s commercialization should be dealt with by them. If this function doesn’t exist, over and above all their other responsibilities, I think product owners need to deal with the following aspects of product commercialization (with examples):

Auto updating: Without a site visit.
Billing: Without human intervention.
Customer experience management: Key moments-of-truth are managed.
Communications: Case-specific communications are enabled.
Content: Content IP is banked.
Contracting: Customers are able to contract quickly and easily.
Licensing: License model supports the financial model.
Networking and lists: Software enables building of hard-to-replicate networks and lists.
Performance: Exceeds the reasonable customer’s expectation.
Reporting: Enables management decision making.
Rights management: Render (print/view/play), transport (copy/move/loan), and derivative work rights (extract/edit/embed) are managed, as required.
Support: Without a site visit.
Traceability: Customizations are traceable and known.
Training: Training available online and material updateable independent of software release.
User interface: Business IP banked.
Web site: E-Commerce IP banked.
Work flow: Process IP banked.

Where should you be able to spot product owners plying their trade? Alongside stakeholders, co-located with the team, and out in the market place. (And to those who manage product owners, please outline their duties and responsibilities in a job description, and have regular performance appraisals with them. Product owners, like others, need to know how they are performing.)

What should they be doing? Product owners should always be busy with delivering the right solution to the market, one which meets user needs in the context of their jobs or other tasks, and which achieves stakeholder objectives. In doing this product owners must continually identify, aggregate, and prioritize stakeholder expectations, features and related benefits, and user needs.

What kind of solutions should you expect to come out of teams with strong product owner leadership? In the first place, expect their solutions to be innovative: Not the same as was previously done; different; fresh; inventive; new; novel; original; unfamiliar; unprecedented. In other words, the right thing for the moment.

Secondly, expect solutions to be ethical: Complying with your organization’s accepted principles of right and wrong; moral; principled; proper. In other words, in the right way.

And lastly, expect solutions to be respectful: Marked by courteous submission or respect; deferential; duteous; dutiful. In other words, respectful of others’ rights.

What characteristics and qualities should you look for in product owners? In my experience good product owners are those who can prioritize lots of tasks, who manage by influence, who are more comfortable with coordinating than planning, and who balance competing perspectives. Product owners should have good interpersonal skills, especially listening.

In my mind product owners need to be strong and courageous, passionate, creative, and all heart.

A product owner wants to challenge the way things work, support a cause, make some history, and over deliver. And over delivery is about creating larger capacity people: Stakeholders who dream bigger dreams; teams who become more productive; and, users who feel more capable in their jobs or tasks.

So, I define a Scrum product owner like this:

A product owner directs the team to deliver the right solution to market that meets user needs and stakeholder expectations, in a way that is innovative, ethical, and respectful of the rights of others.

The last key relationship product owners need to maintain is with the team. And although their relationships with stakeholders and the market are vital in determining what gets built next, it is in the context of the relationship between product owners and the team that the work actually gets done.

The responsibilites a product owner discharges through this relationship are:

1. Direct production to meet stakeholder expectations and user needs.
2. Share the product vision with the team.
3. Identify, aggregate and prioritise features and related benefits the product will deliver to users.
4. Prepare and maintain a prioritised list of summarised and detailed work items.
5. Describe product functionality by way of user stories.
6. Negotiate to prioritise work that mitigates technical and financial risk.
7. Prioritise work that accelerates team learning.
8. Validate the product for release, including use of user testing.
9. Decide whether to ship the product.

Lighting the path
Finding the right balance between documenting and doing is an art that still causes some anxiety in the team. And clearly not all documentation is bad. I encourage product owners to use the business case and vision to create a data sheet, which can be used to articulate the broad product vision to the team on a continuing basis.

This document distills out of the vision the principal features of the product, and their related benefits, in user language. If software was still sold off-the-shelf, this would be the promotional material printed on the outside of the box.

The overview is another document I encourage product owners to produce. This artifact contains as many of the product’s features and related benefits that have been conceived at this point, in more detail than the data sheet, but still in user language.

The overview, like the data sheet, still honors the product vision. Because it communicates how the product owner has interpreted the vision, when reading the overview team members often say, “Oh, I didn’t know you meant that. We’ll have to talk it through.” Then if proposed features and benefits need to be discounted for any reason, everyone is aware of the base off of which this is being done.

Obviously sprint planning sessions, sprints, and sprint reviews are opportunities to cement good working relationships with every member of the team. The strength of these relationships will shine through in the product. Keeping the team pointed in the correct direction is facilitated through strong product owner leadership in the product backlog.

With the previous documents in place the product backlog, which is a prioritised list of tasks described as user stories, becomes a doddle to produce.

Following on from the Doing the Business post, which discussed the relationship between product owners and stakeholders, what kind of responsibilities rest on product owners with regard to their product’s market?

1. Identify, aggregate, prioritise user needs.
2. Study and assess new markets, applications, products, and partners.
3. Perform gap analyses.
4. Follow commercial, technological, and legal trends.
5. Develop and maintain access to customer and industry evangelists.
6. Produce innovative, needs-based solutions.
7. Possess a strong understanding of customers’ issues and priorities.
8. Champion the product to internal and external audiences.
9. Study the product domain.

Do you know where you’re going to?
One of the benefits Agile offers is greater transparency, although too often this is only felt inwardly – inside the company.

I like to encourage product owners and their organizations to become comfortable publishing a product road map externally, to customers. This document creates an effective way for the market – as well as internal stakeholders – to view and interact with the product development pipeline.

On this basis, informed and unemotional discussion can be had about priority before inappropriate choices develop into crises.

In my experience, the benefits arising from your market being settled in the knowledge that you have a strategic direction for the product, for which they can plan, often result in customer loyalty.

Tom Peters was recently quoted as saying: “It’s always ‘the people’. It may be glib, but in this instance I don’t care. Network, keep your promises, behave decently. You are as good as your relationships. Period. Short term. Long term. Good times. Tough times. This is the time (though all times are, in fact, the time) to over invest in relationship building and maintenance.”

Although this is generally true in life, it is also particularly true of the relationships between product owners and stakeholders, users, and the team.

What kind of product owner responsibilities can be discharged through good working relationships between them and stakeholders?

1. Identify, aggregate and prioritise stakeholder commercial objectives and expectations.
2. Play a leadership role in determining product strategy and direction.
3. Influence or negotiate key strategy decision points and milestones.
4. Identify, establish and maintain, strategic relationships with key internal and external decision-makers and stakeholders.
5. Form and maintain the product vision.
6. Identify, contract, and maintain, business relationships that defend the product against strategic threats, create defensible competitive advantages, profitably grow existing business, and exploit or create new market opportunities.
7. Develop innovative product recommendations based on commercial, technical, and legal assessments.
8. Participate in developing business cases.
9. Identify and drive corporate themes through the product.

My view is that these responsibilities should themselves be treated with agility: In other words meet them in the context of the product, the business, and the other roles in the organization, like Product Managers for example.

A long one instead
How do product owners sense they are moving towards their objective of meeting stakeholder expectations?

Spend time with them. Apart from day-to-day interactions with stakeholders I usually encourage product owners to host regular sessions with them to in order to articulate key business risks and opportunities.

Having something sensible to say to busy executives who have committed their valuable time means that beforehand product owners should have mapped their products’ ‘DNA’ to provide a framework to discuss current and future product initiatives. It may prove handy to refer to a conceptual model, and a trading community model, during these sessions as well.

In my opinion nothing creates a visceral connection between product owners and their product like a business case and vision. Although products owners groan when I say they should write and maintain these artifacts, they are not the 100-page tomes of the past.

Mark Twain once apologized to his readers: “I didn’t have time to write a short letter, so I wrote a long one instead.” This shouldn’t be the approach product owners take with these documents: 3 pages for a business case and 4 for a vision. The outcome of the stakeholder sessions should be that the content of these documents is confirmed and updated.

Distilling out the product vision into a goal model is also a useful exercise, I’ve found.

I thought you may be interested in an article by Derick Bailey. As Derick says, “I know I’m going to rile up some of the Scrum fundamentalists out there.”

“Given my current feelings about Scrum and Kanban, I thought it would be appropriate to outline how I think time boxes and Kanban can coexist,” says Bailey. You can read the full article here.

It cuts both ways: Technical competence. Having highly competent people on your Team can make or break your project.

Genius, geek, propeller-head – just some of the labels we place on people who are gifted in technical insight and skills. And it’s great when they come through for the project, solving a difficult problem that’s been holding the Team back.

Yet you must also be familiar with this scene: You’re meeting with the Team explaining your vision for a new product or feature, and as you’re talking you glance across at the major brain in the room. His eyes are glassy; he has that distant look about him.

An impact, either way
Yes, he’s started to make decisions, design the architecture, code the system, right there, in his head.

And while this hyper-productivity may be admirable, it’s questionable whether it is functionally effective towards meeting your project’s objectives. After all, you haven’t finished imparting the vision.

The code that’s written at that moment, in his head, may have a significant impact on your project’s success. Has he heard everything of significance? Has he factored it all in? How strongly is he able to exert his will over others? Are other team members included or squeezed out from that point? If he’s made a wrong call, does he have the emotional intelligence to back down?

Technical competence can be a powerful ally to market place success, but it can just as easily confine your product to the ranks of the also-rans.

Reaping rewards comes after mitigating risk. Bringing the Team’s technical competence to bear at the right time and in the right way will give your product a shot at greatness.

A lot, actually. Take bureaucracy, for example: It’s likely that the word is perceived negatively by you and many others. Judging by public opinion one would be forgiven for thinking that this organizing principle has had a bad effect on society.

Yet as a principle, bureaucracy has been tremendously successful over thousands of years, evidenced by the fact that it is the mother of all incumbent systems today. During the 17th century bureaucracy, or ‘rule by office’ became an effective counter measure to governments being staffed by friends, relatives, or those of a particular social or ethnic group.

By definition a bureaucracy is rational, neutral, and merit-based. Perhaps it’s getting the blame for the effects of something else. To my mind the real enemy has and may always be self-interest.

A great article by Tobias Mayer from the Agile Anarchy site, pointing out that to truly live Scrum needs a heart: This heart is the task board.

Book review: The Future of the Internet – And How to Stop It, by Jonathan L Zittrain.

“The framers of the Internet did not design their network with visions of mainstream dominance. Instead, the very unexpectedness of its success was a critical ingredient,” says Jonathan Zittrain in his free e-book The Future of the Internet – And How to Stop It.

“The Internet was able to develop quietly and organically for years before it became widely known, remaining outside the notice of those who would have insisted on more cautious strictures had they only suspected how ubiquitous it would become.”

Sea change
Yet Zittrain raises a concern that the Internet may be headed for a more controlled future. “With the unwitting help of its users, the generative Internet is on a path to a lockdown, ending its cycle of innovation—and facilitating unsettling new kinds of control. As tethered appliances and applications eclipse the PC, the very nature of the Internet—its “generativity,” or innovative character—is at risk.”

In a recent article in ComputerWorld, Zittrain responds to criticism of his view of cloud computing.

“I don’t begrudge operators of cloud-based services,” Zittrain says, “or vendors wanting to sell or consult about exciting new cloud technology, their enthusiasm about ubiquitous networks-or their outrage when they feel their parade being rained on a little.

“But for the areas many of us should be caring and thinking about, the sea change occurring in our control over our code and content must be addressed, especially since the move to the cloud can be appealing for so many other reasons.”

Whenever I can I like to spend time with customer care people, trainers, sales people, and those who support our products in the market place. Why? Because as a manager I must always be aware of how our products are being portrayed to customers and users: Over the ‘phone, in emails, in Help and FAQs, in training, in sales demo’s, everywhere.

In his book On War, published posthumously by his wife in 1832, von Clausewitz wrote, “We fall into error if we attribute to strategy a power independent of tactical results.”

Is your strategy being made impotent by rudeness over the ‘phone, poor grammar in emails, incomplete or inaccurate Help, dour trainers, or over-promising and under-delivering sales people? You need to find out.