Revisiting Customer and Business Value

  • Architectural Capability;
  • Developer Efficiency;
  • Data Use.

Architectural Capability

I have a bone to pick with the concept of an MVP — not specifically with the approach. I absolutely agree that the most important thing for a startup is to build something quickly, get customer feedback and iterate. Lots of BML (Build, Measure, Learn) loops are imperative.

Future Proofing

Product Managers and Engineers may omit future-proofing for a number of reasons:

  • They may not be equipped with the skills or experience to spot potential areas to future proof;
  • They are pushed to deliver fast and take the shortest path to victory;
  • They are pushed to cut corners (skipping the design phase, missing technical operational concerns etc…);
  • The perception is that the initial investment is too long, doesn’t deliver value and it’s better to build the quick solution instead.
  • Building marketing content and copy directly into a codebase in templates, resource bundles or code;
  • Coding complex business rules with zero flexibility (think conditional statements) into a product.

Products without the codez

Sometimes, there is a clear benefit in moving things away from the developers into the hands of business users. Conversely, sometimes this is also very dangerous depending on the scenario : ) In a recent panel I was involved with recently on “Achieving the Perfect Engineering/Product Relationship” one of the speakers remarked on an excellent question that engineering teams should be asked.

How do we build this without writing code?

Alternatively, how can we build this with the minimal amount of code, or by using an off the shelf solution. If you want to sell something online you don’t write a storefront right? You look for solutions off-the-shelf that allow you to move more quickly. The same goes with more nuanced solutions, but often it’s not obvious how you would assemble software to achieve the same sort of result. No-code and low-code solutions have helped here along with integration platforms like Zapier and Integromat.

Thanks Drew Beamer —

The Value of Developer Efficiency

Development is costly — anytime you ask an engineer to build something, there are a number of other things that come into play in addition to the time it takes to write the code required:

  • The time to understand where in the codebase the changes need to be made, structural changes and components that need to be changed as a result of this. Code readability and comprehension ability play a huge part here;
  • The time to write unit, integration and acceptance tests, especially if we’re dealing with legacy code that comes with no safety net to catch issues — production screwups galore!
  • Source control time (ok, minimal), but still, branch, change, commit, push, merge etc…
  • The time it takes to actually build the product in CI/CD and the dependencies;
  • The time it takes for someone to prepare the release, write the release notes;
  • The time required to deploy the software into production — exasperated if this is a manual process, also exasperated if you have a complex microservices architecture with dependencies, multiple databases etc…;
  • 30 Min Build Time — 22.5 hours or nearly four developer days;
  • 15 Min Build Time — 11.25 hours or nearly two developer days;
Developers, Developers, Developers —

The Value of Data

Data is a funny initiative, it doesn’t really sit in one team. It permeates and is distributed around the business. It is layered and hierarchical. Product managers are involved in data analysis, but rarely involved more deeply in the exploratory side of data. Enter Data Scientists, who are charged with analysis, but also with hypothesis generation and applying outcomes from that to the business, but also to products. Take machine learning and the application of predicting taxi fare rides and the subsequent injection of that into a product to provide “value to the customer”. There is value within the data you collect in your operational systems, and that can be used to improve customer experience and to improve efficiency of your business workflows, amongst others.

The Value of Engineer Decisions and the Platform

Engineers get a fairly rough time when it comes to “ideation”, often because they rush to the keyboard to solutionise and write code. Using this as a stick to beat them with is unfair though, and it’s critical that product managers understand the “Platform Roadmap” as well as the more commonly discussed technical debt concept. It’s crucial to understand the opportunities that help with productivity, shortcuts between different build stages.

Holistic Roadmap Value (Platform, Data, Product)

Both data and platform deserve a roadmap in their own right that are used along with the product roadmap during the negotiation for objectives for a given quarter and a plan for the year. Don’t just focus on a single product roadmap — you’ll end up with a house of cards that is a pain to maintain, annoys your customers who eventually hate your product and leave.

The Shortest Path To Victory – Pitfalls

I’ve seen a scenario previously where a team had been asked to build a feature at speed (shortest path to victory) for a business.

  • Lack of appropriate logging for the feature – the developers couldn’t explain what was happening in the system;
  • Lack of any tooling or admin UI for inspection – logging would have been a start!;
  • Lack of tests utilising real-world data – resulting in edge cases which caused the system to break for the end users.
  • “We need to understand how well this algorithm is performing, how often does it work and how often does it fail?”
  • “We need to log and store input/outputs for this feature in order to debug and improve the algorithm once this goes live”
  • We need a set of integration tests that use synthetic data (derived from real-world data) that allow us to test how well this algorithm does using known data.

In Conclusion

Don’t just focus on customer value, consider the whole picture in terms of value and how you deliver that value to consumers. Look at:

  • The efficiency of the engineering team and factor in time for this;
  • Look at alternatives to writing code and consider asking the future-proofing questions;
  • Consider data and operational aspects to ensure observability and ultimate customer success.



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