Scrum as a Product Requirement

I’ve been asked more than once if it is within Product Management’s purview to prescribe a product development or project management methodology.gears Experience has taught me that Scrum works, and I believe that it is within my authority to prescribe a process through which I believe success to be possible, and perhaps more importantly to veto a process that I know to be doomed for failure.

I was recently asked to make this case in writing and was pleasantly surprised at the results. I feel like I’ve stated the case for Scrum – or something quite close – with legitimate business reasons. Following is an excerpt from a product charter document on the subject of project management:

This project will be executed under a somewhat unique set of circumstances. Selection of a project management process that supports these circumstances is critical to the success of the project. It is the responsibility of The Team (Executive, Product, and Development) to select a project management process that will be used for the lifetime of the project. Following is a discussion of the circumstances of the project along with indications for the project management process.

This project is not being fulfilled for a single customer. We are building to where we believe the market will be in one year’s time – our perception of where exactly that is will very likely change over the next 12 months. For this reason we must follow a project management process that allows for continuous adaptation of the project deliverables.

The company has a rather small team of highly qualified and experienced software developers who have worked together for many years. Such a team will not be helped by a heavyweight process, but more likely hindered by it; clearly this is not desirable. Therefore a second requirement on the project management process is that it be “lightweight”. In other words the artifacts of the process must be few and straightforward, requiring minimal documentation and creating little process overhead.

Accountability for product strategy lies with the SVP Product & Strategy. In practice, however, the responsibility for defining product strategy is shared across multiple organizational disciplines including Executive, Development, and Sales. An additional requirement on the project management process then, is that it must provide transparency to in-flight development in order to facilitate shared responsibility for product strategy.

Finally, we anticipate a great deal of interest in this project from existing customers, prospects, board members, prospective investors, and press. To maintain credibility, we cannot afford to have discrepancies between reports on project status. We must speak to all external stakeholders with a single accurate voice. A final requirement on the project management process is that it must allow for measurement of progress towards goals and milestones.

I’m curious how the selection of methodology/process is decided at your shop. Does PM prescribe it, do they even have a voice? Also curious what you think of my argument above.


If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.


Speaking out of context, my initial read is that this is very heavy and un-agile like. It is good to have it written down because it can be referenced. At the same time, it may not be read because it is so technical (IMO). But I digress.

Back to the original question: Product Management’s purview to prescribe a product development or project management methodology

Unequivocally, Yes. The product manager is supposed to have the global view. This would be akin to being the CEO of the product (different topic). As such, you are entrusted with the success of the product. If something is not working, feature, process, technology, etc. someone should flag it. Ultimately, I think the buck stops with the PM.

That said, you cannot be changing things midstream without good reasons. That also jeopardizes the products success. There are natural inflection points where course corrections can be implemented. When entertaining this though, I would recommend to over communicate the need. As the PM (with no authority) you want as many allies as you can get to ensure the change is successful. People tend to get on-board when they understand why.

As a software developer I really happy to got the little piece of info about Product Management. I enjoyed this input. Thanks!

Leave a comment