From product management

A View on Product Ownership vs. Management

In order for companies to successfully adopt Agile development methodologies, a good place to start is to properly define and assign the Product Owner vs. the Product Manager roles.  Or, to combine these two roles into one until the product is mature enough or the market is diverse enough to warrant separate positions (but more on that later..).

In general, what I’ve read regarding Product Manager versus Product Owner responsibilities is right on the money (refer to blog post links on this topic at the end of this article).  For example, Product Owners tend to focus internally and work closely with development teams to ensure successful delivery against published timelines.  Conversely, Product Managers work externally with non-development functions, such as Sales, Marketing, and Customer Service, and with customers to ensure financial and market success for a product.  Here’s a quick summary of additional key differences:

Product Owner Product Manager
Internal focus External focus
Execution objectives Strategy/Financial objectives
Single function (Development) Cross functional
Mature product Early stage product
Reports to IT Reports to business/CEO
Delivery Success Commercial Success
User Centric Buyer Centric
Post MVP Release MVP Construction
Single Customer Market of Customers

Titles can also vary for Product Owners and Product Managers and can help clarify to the organization their primary objectives.  Product Owners often report up through the IT organization, are primarily responsible for backlog prioritization, and collaborate closely with development teams.  Therefore, they may be titled as Technical Product Managers, Inbound Product Managers, Backlog Managers or Business Analysts.

Product Managers, due to their business oriented goals for the product can assume titles such as Product Marketing Manager, Business Owner, Commercial Product Manager, or Strategy Product Manager. Product Management often reports directly to the CEO or through a business oriented function such as Sales, Marketing, or Operations.

The bigger question, however, is do these 2 roles need to exist as separate positions in your organization?  If your product or service is targeting a single customer, then the answer is probably no.  Your single customer could be an internal operating division, a target user for your MVP, or a client for your customized solution.  However, if your product serves a diverse market of users or is growing beyond a narrowly targeted MVP to address multiple business pains, your organization likely needs both a Product Owner and Product Manager to manage the volume of product management tasks.

To provide some perspective, I’ll share what I’ve seen work managing products at both start-up and large organizations.

There’s no question that small startups, where the pressure is intense to build a product quickly and gain traction efficiently, should combine these 2 roles into one.  Furthermore, this person should be sitting right next to the development team.  At my first start-up, the developers, consultants, and myself all shared a small office and it worked wonders.  We openly talked about how the newest customers were using our software and how the latest sales presentation went (we all sat within earshot of one another).  When a customer service call came in, the call would be forwarded to whomever was available. Then we’d share what was just discussed (if it wasn’t obvious already).  By having a single point of product contact and co-locating that person with the rest of the team, we always knew we were working on the most important things and could be immediately responsive to any questions that came up.

Similarly, at 2 subsequent startups where we used 3rd party development shops, it was advantageous for me to be the single point of contact. Developing without clear goals or not developing while awaiting responses to questions from remotely (often 6-8 time zones away) located teams could add unnecessary hours to our tab.

At large organizations serving a diverse marketplace with mature products, these 2 roles should be separated. The bandwidth required to manage a backlog and keep a development team on track requires that a Product Owner be a dedicated role.  The Product Owner should work closely with the Product Manager to free up his/her time to focus on business objective oriented product activities. In a sense, the Product Owner becomes an extension of the Product Manger, like a point guard is an on-court extension of the basketball coach ensuring that the team is working together effectively.

At the large enterprise software company where I served as Product Manager, we didn’t have a separate Product Owner role. The responsibilities were shared between myself and the Development Team manager, thus diluting our respective effectiveness. She was constantly having to hunt me down to ask questions while I spent inordinate amounts of time documenting requirements since I couldn’t be as available as she’d have preferred to attend development team meetings and respond to emails.

I also witnessed the dysfunction of not clearly defining these 2 roles at a large organization experiencing rapid growth.  We were a B2C company but the development teams were building internal systems to help the business operate more efficiently, i.e. a single customer. There were Product Managers but they operated more like Product Owners – managing the backlog, attending daily scrum meetings, and writing technical requirements.  While they collaborated daily with the development teams (a portion of whom were located in India), they were on the west coast while the customer (i.e. internal operations teams) were in Chicago making it difficult to understand the needs of the business.  There were business analysts, operations managers, and finance managers in the Chicago office that all contributed to the dialogue about what was needed to best support the business.  But there wasn’t a true Product Manager whose singular focus was to ensure success against and clearly communicate business goals. Confusion about what was being delivered (and when) and frequently missed delivery dates ensued.

In conclusion, there are business environments where both a Product Manager and Product Owner are needed and others where these roles should be combined.  Regardless of the structure, however, it is imperative to clearly define and communicate these roles throughout the organization.

Good Blog Postings on the Topic:

The Clever PM: Understanding the Difference Between Product Managers and Product Owners
The PM Vision: Duties of Product Manager vs Product Owner Responsibilities & Product Ownership and Management in B2B Commercial Software
Product Focus: A Product Owner is not a Product Manager
On Product Management: The Scrum Title “Product Owner” must die!

Can a Founder Possess an Ecosystem?

Ecosystems in technology are often discussed in terms of geographical concentrations of supporting resources or platform based concentrations of aligned applications. The obvious geographical winner is Silicon Valley and its aligned resources of entrepreneurs, funders, coders, and mentors.  Smaller examples include co-working spaces, incubators, and Meetup groups.  Platform ecosystems include, iOS/Android/Windows, and Facebook.

But what about the ecosystem that a Founder brings to a startup?  Might there be a similar collection of resources that an individual brings with him/her that enhances and is enhanced by the addition of other startup ingredients? Within certain founder’s ecosystems, do new ideas, people, and money have a greater chance at seeing success than others?

There is plenty of discussion about what makes a good founder (or product manager).  There are many good top skills lists or areas of excellence lists to choose from see what an individual needs to bring to the table to execute well (e.g. curiosity, passion, humility, fact based decision making, etc.). And equally many guides on which tasks to execute, who should execute them and their proper sequence (e.g. product discovery -> build mocks -> code -> user test -> iterate -> launch -> measure).

However, the ecosystem that a product manager or founder possesses can make the difference between success and failure. The good news is that the ‘right’ environment and ‘ideal’ collection of resources are not a matter of luck and can be developed, just like good product management and launch execution skills can.  They just might take a bit longer to build depending on your background and situation.

My personal experience in helping to launch 3 companies (2 of which failed to gain traction) provide vivid examples of this ‘founder ecosystem’ theory. The company which succeeded was my first and, unfortunately, it took struggling through the two subsequent failures to fully appreciate this concept.

The big 3 ecosystem factors that I believe enhance a founder’s odds of minimizing the trough of sorrow and reaching the pinnacle of ecstasy are as follows:

  • Robust network of industry contacts
  • Close relationships with target customers
  • Deep user perspective on competing products

Robust network of industry contacts

Being able to assess product-market fit and determine a solid go to market strategy are all greatly enhanced if you possess a wide range of contacts in your chosen industry.  Before start-up #1 (the successful one), I had spent 4 years in consulting working alongside other industry professionals from both vendors and prospective customers.  When it came time to determine whether my new product idea would work, I could easily pick up the phone and inquire about whether they’d seen anything similar, what they thought of it, and what their frustration was by not having a better solution. Having attended trade shows and user conferences, I knew people who could provide equally valuable perspective on the market, the direction it’s heading, and any emerging competitors to note.

On a subsequent startup which played in the private aviation market, all I had were a few connections from my time learning how to fly. These contacts (mostly other pilots) knew where to find the best $150 hamburger in the area.  But they hardly had any idea whether existing private jet fliers were seeking lower cost alternatives or whether potential strategic partners would be interested in offering a lower priced service. However, I met as many people as possible by networking at industry trade events, emailing bloggers, setting up meetings with key players in the local charter aviation community, and cold calling industry leaders. I was eventually able to build up a decent network of industry contacts but it took about 2 years.  Valuable time that had opportunity costs.  I could have avoided several missteps and determined more quickly the difficulty of the service I was attempting to build had I started with this network in hand.

Close relationships with target customers

Back to startup #1 and the consulting I had done in the years leading up to breaking free to launch my business. I had been working day in and day out with prospective users, beneficiaries (of my potential idea), and decision makers – all influencers in the buying process. Understanding the buying process is critical to knowing how to sell your product or service. For example, I knew that users had very little appetite or time to learn new solutions so the product had to be simple to configure. I also had experienced first hand the inefficient work being created by existing solutions (which were often spreadsheets) so could authoritatively speak to and quantify benefits. Lastly, I had participated in their software RFP processes for similar solutions so knew the big questions and concerns that key decision makers would have during the sales process.

Conversely in startup #2, I hadn’t spoken with more than a handful of people who had flown on private jets before (our ideal target customer) nor had any idea how individuals or corporations made decisions about their private aviation spending. There were critical factors I discovered like the importance of demonstrating a track record of safety, reliable personnel tracking, and confidentiality of on board conversations that made a multi-entity private jet trip unappealing to certain segments of the market.  Similarly, the aviation broker business structure I was proposing for the company had a seedy reputation in the industry and it took some time to figure out how to position our solution and get ahead of prospective customer concerns.  The sales process for our proposed service turned out to be quite a bit more complex than originally anticipated and, again, cost us valuable time to position ourselves well to win sales opportunities.


Deep user perspective on competing products

Perhaps the most valuable benefit of the consulting work I did before startup #1 was participating alongside our clients in documenting software requirements and, in some cases, building (from scratch) necessary tools where existing market solutions couldn’t meet those requirements.  I quickly developed an understanding of current offerings, potential weaknesses to exploit and how to position our solution relative to competing products. Developing RFP materials also gave me unique insight to customers’ primary pain points. Helping implement competing solutions and/or developing Excel tools to perform many of the same or complementary functions provided me valuable information about required MVP features for a commercializable product. Lastly, when it came time to launch our MVP I had a roster of prospective users/testers to help trial our product.

Meanwhile during startup #3, we were attempting to build a sales lead generation & qualification service. I had never consulted with or worked in any pay-per-appointment companies nor had been a buyer of their services. These players were a big part of a lead qualification industry we were hoping to disrupt. It took a fair amount of research to determine these off-line competitors’ pricing models, key selling points, and contractual arrangements. Understanding these components were necessary to offering a service that prospective buyers would easily be able to compare to existing ones. In pure product terms, I wish I had seen the quality and volume of data these companies wrestled with to develop good call lists for customers. Or had been a buyer for services to see first hand the challenges these companies had in pitching products well and finding quality leads. Otherwise, we would’ve had a much greater appreciation for the necessity to partner with and a data service company sooner in our launch. Doing so extended our MVP completion by at least 6 additional months – an effort that risked our goal of being first to market.

In summary, these three ecosystem factors won’t guarantee success with your new product or company launch.  But it will certainly help you avoid launch delays, better position your solution, and win a higher percentage of customers upon launch. And should be equally considered alongside the quality of product leadership, team makeup, and launch plans when evaluating a startup’s (or founder’s) odds for success.