In a model like Red Arrow’s, we’re working with new clients and new markets all the time. We do a good job of picking up the business from our clients, but fully understanding and absorbing the subject matter to become an expert can take a lot of time – often longer than our projects even last. In these sorts of projects, the importance of strong product ownership is really emphasized.
Someone smart once said, “If you can make an acronym out of it, it must be true.” (Well, maybe I just made that up, but at least an acronym might help you remember some key points.) With that, I give you my “FLAKE” theory of good product ownership.
- Available (and Active)
A good product owner allows the team to make the decisions about designing and building the application. His or her input is still critical, but it focuses mostly on ensuring that business needs are being met – not by dictating implementation. A flexible product owner has a vision of the endpoint, but is flexible about how the development team gets there.
Available (and Active)
Especially in a custom development model, the person who takes the product owner role usually does so as just a small part of his or her day-to-day activities. For our projects, the product owner is often a president or other executive in a company who has the idea for the application. Unfortunately, executives are often pretty busy, which can make it difficult to get the attention from them that the project needs to be really successful.
The ideal product owner will be both available and actively involved in the project. They don’t need to be available at the drop of a hat, but they do need to respond to questions within a reasonable amount of time. They also need to allocate time to review the necessary project artifacts, like the user stories and wireframes.
Most of the companies we work with have years and years of experience in their particular market. Though it’s important for our development team (especially our analysts) to understand that business as much as is possible, it’s unrealistic to think we’ll develop the breadth and depth that long-time employees at our client have.
Because of that, it’s important for a product owner to be someone who is knowledgeable about their business. The product owner needs to understand the goals of the project, the users of the application, and other driving business factors (like capabilities of competitors’ solutions, for example).
Finally, the product owner needs to be someone who is empowered to make decisions. To keep developing at a fast pace, it’s important to have a product owner who has the power to make the call when it comes to project priorities or other such decisions. It’s not to say that the product owner can’t take a “time out” to go do some research, or gather consensus from other stakeholders. However, if the product owner can’t make simple calls without consulting a whole committee, or when that product owner’s decisions are constantly being overturned by other stakeholders behind the scenes, it can cause a lot of unnecessary churn and wasted time.
Flake, but not flaky
So, I went with FLAKE because it was mildly humorous and because the acronym fit with some of the attributes I found important (and because FREAK was my next best option). But it’s probably pretty obvious that a good product owner is far from flaky. Having a FLAKE product owner goes a long way to ensuring a fast, smooth, successful product and project.