How did product people misinterpret the concept of the requirements?

I am a systems engineer and program manager and while I have years of experience managing product development, it’s mostly from an engineer’s perspective. So I am new to the whole product management body of knowledge and maybe naïve to some extent. But what gurus of product management tell us about program management and ‘the waterfall development model’ always felt wrong to me. Particularly, the notion of working with requirements specifications that turned to systems architecture, and to design specs, which are implemented, tested, and validated downstream aka ‘the waterfall’. In (Cagan, 2017) you can find an explanation of how crippled this process is if you compare it to ‘the incremental product development’ (which is a spiral life cycle model systems engineers came up with dozens of years ago btw). Well, I always disagreed with such an understanding of the process, because a qualified systems engineer, solution or systems architect, or program manager will never just accept the spec and proceed to implement it with no questions asked from stakeholders or customers. It never worked like that in my experience. Who writes the specification must understand the solution, at least to some extent, as well as the operations domain. The specification (even baselined) is never a fact, it is the set of hypotheses you must inquire about, validate, and only then implement. ‘The waterfall’ is not linear and never was (Dischave, 2012; Petersen et al., 2009).

But just pointing to that misinterpretation does not have any practical sense. There must be a remedy, tool, or technique that addresses the need for requirements specification analysis and inquiry. And in PPI SyEN edition 113, June 2022 issue I found the most practical and elegant solution I’ve witnessed until today — the Decision Blitz technique.

Fitch, J., 2022. Reverse Engineering Stakeholder Decisions from Their Requirements. Project Performance International.

Template for reverse-engineering the underlying decisions

The idea behind Decision Blitz is very simple — every requirement is a product of some decision taken. Until you have discovered what decision it was, you don’t understand the specification. Technique explains how you really read the requirement spec before you implement it. And the work product of such a reverse engineering decisions process is a decision tree, the artifact you can discuss with any stakeholder because it is so obvious and useful. Read this brief article if you write or read the requirement, it’s so concise and enlightening.

It is not the first time I see the occurring pattern. You cannot say that you have understood the design document if after you studied it you didn’t produce another well-structured and meaningful work product. In intellectual work, you cannot just absorb ideas, you must make them your own, and generate the result. In the practical aspect that means on each end of the organizational interface, both on the sender and receiver, there are different types of artifacts. One encapsulates the sender’s understanding and another one encapsulates the receiver’s understanding. Copy-paste does not work and metacortex is what everyone needs.

Sources

Cagan, M., 2017. INSPIRED: How to Create Tech Products Customers Love, 2nd edition. Wiley.

Dischave, D., 2012. A Waterfall Systems Development Methodology … Seriously? URL https://web.archive.org/web/20150316113731/http://get.syr.edu/news_alt.aspx?recid=401 (accessed 7.3.22).

Petersen, K., Wohlin, C., Baca, D., 2009. The waterfall model in large-scale development, in: International Conference on Product-Focused Software Process Improvement. Springer, pp. 386–400.

Fitch, J., 2022. Reverse Engineering Stakeholder Decisions from Their Requirements. Project Performance International.

Fitch, J., 2016. Reverse Engineer to go farther/faster. Decision Driven® Solutions Blog. URL https://decisiondriven.wordpress.com/2016/09/14/reverse-engineer-to-go-fartherfaster/ (accessed 7.4.22).

Fitch, J., 2008. Reverse engineering a decision and roadmap baseline. Decision Driven® Solutions Blog. URL https://decisiondriven.wordpress.com/2008/08/19/reverse-engineering-a-decision-and-roadmap-baseline/ (accessed 7.4.22).

Fitch, J.A., 2016. Product Scoping Decisions. Decision Driven® Solutions Blog. URL https://decisiondriven.wordpress.com/2016/08/30/product-scoping-decisions/ (accessed 7.4.22).

Mendonza, P., Fitch, J.A., 2012. 2.2. 1 Decision Management (DM) as the engine for scalable cross domain Systems Engineering (SE), in: INCOSE International Symposium. Wiley Online Library, pp. 241–254.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store