The Software Industry needs more Full Stack Product Owners (FSPO)

What is this term that I have coined as "FSPO" or "Full Stack Product Owner"?

An FSPO is an organization member that leaves their usual duties for a given amount of time to focus on delivering software that resolves challenges presented in their daily line of work.

An FSPO is a stakeholder first, then a product owner (PO) after, not the reverse. It is wearing these two hats, what makes an FSPO as effective as a Full Stack Developer (FSD). The existence of an FSPO for a minimal marketable feature (MMF) will reduce the number of people involved in providing a solution and with it the transaction costs related to its delivery. I personally have empirically demonstrated that depending on the availability and commitment of stakeholders we can get 5 to 10 times faster deliveries when an FSPO is put in charge of any MMF versus having a Stakeholder and a PO in charge of the same MMF.

An FSPO is not needed though when the given MMF can be deployed to production without acceptance from stakeholders. When this happens the PO is enough because the transaction costs are zero. This occurs when the PO is a subject matter expert in the Product or the feature being enhanced and has earned the two qualities that any FSPO must possess: responsibility and authority to deliver the specific MMF.

Using the FSPO role saves big dollars in the SDLC, however the challenge is to find people that can perform this job. Just as with finding FSD, this is a scarce resource. The introduction of the FSPO role represents a literal inversion of control (IoC) for product delivery because instead of the traditional "tell me what you want, here is what I understood, here it goes again after teh feddback loop 1, here it goes again after the feedback loop 2 ..." we go with "you tell me to do this and here it is to a T".

The FSPO performs a number of duties:

1. Create a wireframe specification (wf-spec) for the very low fidelity conceived UI/UX. This can be influenced by a UI/UX expert but in many cases, specially those related to ongoing applications, such step is not necessary. This is definitely influenced by other stakeholders.
2. Create an outline of functional and non functional requirements for the MMF. This brainstorming specification (br-spec) is influenced by a number of other stakeholders.
3. Create end to end specifications (e2e-spec). This will be influenced by software developers as they collectively will need to find ways to implement the assertions being requested.
4. Review automated e2e-spec implementations (automated e2e tests) delivered by developers often and on demand.
5. Test the MMF deployed in dev servers often and on demand.
6. Test the MMF in full when deployed to the test environment and all e2e tests have passed per the continuous integration (CI) service.
7. Smoke test the MMF when deployed into the production environment.
8. Classify issues as bugs when the developer did not follow the e2e-spec to a T or defects when the specification itself was faulty.
9. Keep track of the development pace and find the root cause of slowness. Apply theory of constraints to get the pace back up.
10. Get back to their organization duties using the features they themselves help to create and collecting the next round of enhancements, calculate their possible return, risk and statistics-backed cost to help with the authorization from the prioritization comittee.

A good starting point to hire an FSPO is to present this need to each future organization member who regardless will need to become a stakeholder. A second important point is to have a lean, company wide deployed, process engineering. Usually this means that the CMMI level of the company in question must be high. This should be the case if the company is already using end to end (e2e) test driven development. This is because e2e specfications (e2e-spec) solve problems in a simple and precise manner and they are also not difficult to understand for organization members that are experienced in their daily jobs but lacking exposure to develop software.

Ultimately all stakeholders that wish to become FSPO will get a big bump in their professional careers as technology continues to increase its importance when it comes to enabling the success of the organization. The introduction therefore of the FSPO role is a win-win for the Organization and the Stakeholder.