Build, Measure, Learn: How important is quality Software Engineering to Products from a Product Owners perspective?

How important is software engineering to me as a Product Owner? This is a topic that came up recently when tech group in Manchester Manchester Tech Nights were hosting a night on Software Engineering from several different points of view.

It is a topic that prompted a lot of thought for me so and its spurred me to write about it. I love working in Product and even more so I love working in the digital sector. I find that when we build things it is such incredibly rewarding to experience those things get interacted with and used on a daily basis — even more so when you can get some qualitative and quantitative data that the things that you’re building are delivering benefit for the users and for the business.

But I’m just a Product Owner and one part of a larger team. Whilst sometimes I might wear many hats — I am not the one who creates the interface designs nor am I the one who writes the code (and frankly you really wouldn’t want me to!). So, as the the first in a series of articles I’ll be writing, this article will explore the topic of ‘How important is Engineering to me as a Product Owner’. This will form part number of pieces on the Build, Measure, Learn series that I will be writing.

I thought given that I’m only one PO in a collective of PO’s in Manchester (is collective the right noun for a group of PO’s???)— why not reach out to my peers and ask for a few short statements on what Software Engineering means to them? Thankfully they came in, so we’ll go through a few of their statements and discuss them.

“I would lean to calling out software engineering as an important cog in the system bringing technical expertise and capabilities to the forefront. The system can only work and move forward with software engineering in the mix.”

This comment is great and I think it’s the very essence of why quality engineering is so important to me as a PO. Take the world of waterfall projects, we would create requirements documentation (the what) and then feed it off to a team to build a solution (the how). Often what would get delivered was not what was originally intended. Working in Product that relationship between the what and the how needs to be an intimate one.

Personally, I am a big fan of working Lean, building MVP’s before we invest too much into a Product or a Feature and potentially run the risk of it failing. Working this way also means you can collect data whilst you are building the Product to ensure the Product Team is able to deliver the right thing.

When engineering is on board and has a close relationship with the PO, it means that the Product has a much higher likelihood to deliver value.

To explore this take the often-used MVP structure of building a car. We see that for when thinking in MVP structure, we first need to build a skateboard, then a scooter, then a bicycle, then a motorbike and finally a car and learn and progress on the way:

You also often see this image below, attempting to portray not to build this way, where we would build wheels, a frame, a chassis and then finally the car body:

If I as a Product Owner made a decision about which is the best way to progress in these examples above, I could end up making incorrect ones. This could lead to a failed Product or could mean that what the Product ends up delivering doesn’t have value.

To break down the images above, I don’t always know as a Product Owner which path to take. Just how reusable is the skateboard when it comes to the car?

In the second diagram where we make wheels, the frame, the chassis and then the car we could end up having reusable features for the Product. There are benefits in building this way and making reusable components that can be implemented again at another time. If you have an address lookup feature, you don’t want to build multiple address lookup features every time a process calls for one.

If engineering is not in the mix when making decisions about the Product, as a PO I only end up limiting the decisions we can make. If we are working together we can make better decisions.

“Without quality engineering, you don’t have a quality product. All the product ideas in the world are worthless if you can’t implement”.

I’m going to break this out into 2 separate parts:

Turning Product ideas into quality Products with quality engineering.

PO’s are the ones who often make sure that the problem is being defined — we do this so that we can find the right solution. We may be doing this ourselves or we may have analysts help to get there. Nonetheless it falls into our remit to make sure what our Products tackle are real problems so that we can build valuable solutions.

So many Products and Features fail because they go straight to the solution instead of actually addressing the true problem. Once that problem is defined, it should not be us in Product Management to decide what the right solution is from a technical ‘how its built’ way.

We need quality engineering to help decide that - which is why it’s so important to PO’s. I need the team of engineers to tell me how we should build the solution and how we can turn those ideas that we believe will solve the problem into usable Features and Products. There cannot be a quality Product when there isn’t quality engineering involved.

Products need to be built with high quality engineering from the ground up.

2 words — technical debt. If you are not familiar with the concept, it means the debt you accrue by building poorly and/or not maintaining your code, systems and infrastructure. Technical debt and monetary debt are very similar, a little amount of it is fine, but it quickly escalates and grows out of control if not maintained.

Technical debt ruins Companies, Products and Features. Products fail because of it. Take the Blackberry Rim tablet released in 2011. Due to accrued technical debt within their own operating system, Blackberry were not able to build a native email client, messaging client or contacts client in time for the launch date. This meant they launched a Product with the Blackberry name that couldn’t do what Blackberry had become known for. As a consumer would you buy a Blackberry device that couldn’t do what a Blackberry device was known best for?

Quality engineering consideration in building Products is such an important factor as it can cause so much damage. As a PO I am often oblivious to it. I am not the one writing the code nor interacting with the systems to get changes live. But without maintaining it, it means our velocity slows down and ultimately it can even kill the Features or Products we are building. If you work in in eCommerce there is tons of research and data to show that even the tiniest increase in page load times starts to damage your conversion rates.

If you a building web applications and it is built poorly from the start it will take the servers long to serve it, your browser longer to render it and a lot shorter for your users and potential users just to forget about you and move on.

If you are building software and its built poorly from the start — the software potentially ends up full of bugs, instability and ends up being unusable. If you are a SaaS, that’ll kill your Product.

As a PO I need engineering to keep me in the loop about technical debt and I need to ensure that the Roadmap and Backlog take it into account. We have all seen what waves do to sandcastles, Products are the same when users interact with them and you then continue to build on that sand. You need solid foundations and solid building structure from the ground up if it is going to stand the test of time (and an army of users).

“It’s critical that engineering and product drivers are aligned to ensure that delivery is well specified throughout, questioned regularly and delivered to high standard. Product delivery isn’t always about addressing the problem with visual or flow changes, as engineering solutions driven from those of that mind-set to often lead to greater efficiency and more stable products.”

I’m going to break this one down again:

Delivery is specified throughout

I have delivered Products in the past where the timespan between iterations and new Feature delivery starts to grow and grow as the Product Team progresses. I’ve seen this happen to such an extent that you’ve had to bin the Feature or Product entirely. This is often a consequence of the Product not having been thought through from the start. I have found in the past that by not taking into consideration the future when we build current Features they can come back to bite us.

For example — I worked on a Feature to do some search functionality boosting based on keyword and fuzzy data matching that did really well in english language searches. The results were great and it really helped the Product to but when we started to roll out the Feature to other languages we realised it was not scalable. In the end, we ended up pulling the Feature from every other language and it will need a different solution now.

Holding my hands up — this was my fault because I didn’t keep engineering in the loop about the direction of the Product for the future and at the time the Roadmap wasn’t as readily available as it should have been. The engineers in the Product Team built a solution to a problem when it was supplied to them, but there was not a two-way conversation of “is this the right way to build it in consideration for the Product in the future?”.

The Product Team learnt very quickly from this and now we do not build any new Features unless we have consideration for the Roadmap. Engineering are as close to the Roadmap as I am and if it means we spent a little bit more time now to build a Feature that saves us time later, we are willing to invest it.

You will waste time and deliver poor Products if engineering isn’t included throughout the lifespan of the product. You could end up doing what I have done and have to scrap whole Features.

Questioning regularly.

One of the best things you can have in a Product Team is the act of questioning. We always want to make sure that we are going to be delivering benefit and we need to be careful we do not deliver on assumptions, but deliver solutions to real problems.

In all of my Product Teams I’ve always encouraged questioning. If the acceptance criteria is not quite right, or the it isn’t the right it then we need to make sure we realise before we’ve spent time investing too much in it.

As a PO I spend a lot of time with my stakeholders and sponsors, making sure that the direction of the Product is able to deliver benefit. I’m a stickler for always wanting to get down to the route of the problem and not just going right for the solution. I then feed these problems to Product Team, where high level requirements are broken down and we collectively come up with a solution.

When I’ve done this in the past I’ve found that some of the potential solutions end up being quite easy. If for example someone has a problem that they can’t do a certain thing in the CMS, the Engineering team can question if we really need a dedicated Feature for it. They may know that there’s probably a very easy existing way to do it. This saves us time on building whole new features that are not necessarily needed.

Sometimes when you feed the Product Team with the problems and high level requirements everything feels right for a period of time. You could even start building the Feature or Product and something starts to feel funny after a period of time. As a PO I’m often not able to identify if what we are building is potentially going in the wrong direction until there is something in front of me in a show & tell or I am seeing a local version of it on an engineers machine. It is so important to me as a PO that engineering question what we are doing all the time so that we don’t waste time on doing the wrong thing.

Regular questioning by engineering is so important to me as PO as it makes sure that what we deliver has the potential to be the best that I can be. That is why engineering is so important to me.

So, there we have it, a bit of a breakdown of a few different statements on how important engineering is to a Product Owner. What do you think? Let us know in the comments or tweet me @whitmaan .