Following on from the success of our first roundtable event, and the obvious topic to discuss being how to build and embed culture within Engineering teams in an increasingly remote working world, I wanted to get everyone round the table again (virtually) to discuss other relevant topics in the industry.
The event was a great success, with some interesting insights shared between attendees.
Over the last few months, the subject of the relationship between Product and Technology seems to be coming up more and more in conversations I am having with both clients and candidates. Whether it is a customer who is not quite clear on the distinction between a Product Owner and Product Manager, or a CTO who is taking on the responsibility of a Chief Product Officer, I wanted to find out more about the relationship/distinction between Product and Technology teams and their respective roadmaps.
Product vs Technology
For the first talk of the event Martin Pratt, Chief Technology Officer at medudoc education GmbH, and Paul Oostenrijk, Founder at PBJ Studio, spoke about how Product is only a small part of a much bigger picture. Using the analogy of an iceberg they noted that when people talk about Product, they place too much emphasis on the end result, which is just the tip of the iceberg and only a small visible part of a much bigger thing. This is an important detail to note, when talking about Product what are we actually talking about? Companies will often use the term product to encapsulate everything, but when you call it product it puts a lot of emphasis on just the end part of the equation.
This is a common problem in start-ups when founders are often too fixated on what the features are rather than the value that it is actually bringing e.g. the user facing app rather than paying much attention to the parts of the iceberg which are submerged, i.e. core purpose, infrastructure, engineering & DevOps practices, architecture, org structure, etc.
How do companies stop hitting this iceberg that is causing them problems?
A sociotechnical system is essentially the integration of people and technology, and how it functions to achieve a purpose. In start-ups Martin has steered clear of even using the term Minimum Viable Product (MVP) and talks more about Minimum Valuable Solution (MVS). This phrasing focuses in on creating a solution which delivers value against a purpose, rather than focusing on the outcome which may be a product. This value could be of much smaller scope than a traditional “MVP” and used purely to validate certain assumptions you have about the domain, or test the viability of certain ideas. Especially when starting in a new or complex domain you have all these built in assumptions that you have not necessarily validated, and what you want to create a minimum valuable solution for is to just validate some of those assumptions; does (x) work in this particular market, is there actually a market fit here? Etc. Sometimes you will build a prototype which you know will be thrown away because you are really aiming to answer a question/assumption that you already have, rather than being locked into this prototype as being your be all / end all product.
What you are ultimately trying to create is a sociotechnical system (your organisation) which allows you to do this, rather than fixating on creating features of functionality, which may or may not be valuable. Often when people fixate on “Product”, they get caught up in this idea of the MVP being the ultimate end result, and very often struggle to abandon some or all aspects which are not adding value, and even worse sometimes don’t know or measure what value it is adding in the first place.
The sociotechnical systems that you are trying to create encapsulate the responsibilities of the CTO, or in many ways a lot of the c-level suite of making sure that instead of trying to create the features, you are trying to create a culture where the feature can be built as fast, reliable and high quality as possible. Many Product Owners view technology as the development bit and the code you write, whereas technology actually hits all these aspects; How do you track and monitor the requirements, how do you validate the hypothesis or assumptions you had at the beginning if you haven’t built that into the requirements at the start?
Often you will have things not included in the road map because they are not a feature, therefore they are ignored and then they are not estimated, for example how do we deploy the product to users? How do we monitor this thing? How do we make sure we can actually track this? Making sure the build pipeline is included as requirements and having these as part of your road map is key in building an effective sociotechnical system which can sustainably deliver value. These are often ignored by Product Owners because they are just focused on features at the product tip of the iceberg.
Team efficacy is highly influenced by team structure
Building specific roles for product ownership is vital for improved communication flow. Separating these incentives (Product Owner/Manager) into roles can help improve the focus of the development team as usually these incentives are not aligned. As a Product Owner you are really interested in what your customer value looks like, as a Product Manager you are interested in the user but also focused on what the roadmap looks like, what the priorities look like and how they match up.
Having a Product Owner and Product Manager creates that separation and makes it possible for a very effective and faster development speed than if you combined the role. If they are one role then the person has to make sure they have two different mindsets. Product Managers/Owners that are very technical will always put a technical slant on everything and the business minded ones would do the same. It’s very interesting how the communication changes when you separate the roles out to someone who is really caring about the customer and customer values, and wants to achieve the best features possible; and then someone who is really focused on the roadmap and being able to effectively see the holistic product and end result.
Often developers will build features just to get it done, whereas having increased openness and communication with the product manager/management will help improve the focus of the development team as they should be setting a clear roadmap with tasks and discussing these on a regular basis to ensure end user value.
If done poorly then bad Product Management can create an ineffective sociotechnical system and lead to massive technical debt such as incomplete tasks, no acceptance criteria and big gaps in interpretation, which is a huge business risk.
The role of a CTO/CPO
A CTO’s job is not delivering code, designing architecture, or deciding engineering practices, although as CTO especially at a small start-up you may still do some of that. Really a CTO’s job is to ensure your sociotechnical system is effective at delivering value against your organisational purpose.
In regard to how the role works with a CPO, it is really valuable having friction between the two roles. The CPO can focus on external context, business and monetization strategy, providing context and strategic inputs into the system, and navigating critical business risks, whereas the CTO can be more internally focused on optimizing the sociotechnical system, technical innovation, and navigating technical risk. If one person is doing both roles there is arguably too much falling under their remit.
Thank You
I’d like to thank everyone who attended, and the fantastic speakers for contributing to such an insightful and fun evening.
If you are interested in speaking at our next event, or attending one don’t hesitate to contact Third Republic or even the host Richard Atkinson directly.
