An operating model that reflects the day-to-day realities of software delivery

An overview of our product development process, from initial strategy definition and problem statement towards a product definition and software delivery operations at scale.

In our previous blog post, we took a deep dive into the strategic setup and vision of our company: product excellence is a winning strategy. Digital product excellence will only be achieved through a refined day-to-day operating model that places end users on a pedestal and assures frequency, flexibility and quality in software delivery.

Our business model can be summarised as ‘digital product development as a service’. Given the nature of our business, we face two ever-returning questions at the start of a new digital product undertaking:

  1. “How long will ‘it’ take?”
  2. “How much will ‘it’ cost?”

Naturally, we understand the intentions behind these questions, yet there are many dimensions to consider when formulating a correct answer. Here below we will present our thinking and describe our operating model when we set up for delivery success.

Keep your eyes on the prize

We continue to foster a culture of engineering excellence, with respect for the subtleties of the job. There’s a common misunderstanding with regards to the daily activities of a software engineer. Engineers will be spending a majority of their time conceptualising new features, dealing with constraints and aligning with the various product stakeholders. A minority of their time is spent on ‘coding’ in a traditional sense. A great idea in the shower can be more valuable than 8 hours of screen-gazing. That’s why we consider only a single output measure: product value delivery.

We expect every engineer in our team to keep their sights on concrete added value that we create on a sprint-by-sprint basis (a 2-week timeframe).

Essentially, this means two things:

  1. Shipping new features: functionality that ends up in the hands of end users
  2. Code and infrastructure optimisations: improving automated test coverage, server cost reduction, refactoring, etc.

Delivery vs flexibility

It has been well-established that there is a net-positive business case in the long run if you introduce flexibility into the software development process. There’s a simple underlying reason: it’s impossible to define all parameters up-front when you start a new product development trajectory, yet you want your engineers to make good, long-term-oriented decisions in the interest of the product along the way.

The traditional waterfall model based on deadlines and numerous points of failure has rightfully been set aside and replaced with an operating model based on ‘agile’ principles. However, this leaves every organisation (or every product squad) to define its own flavour of agile, operating principles and roles.

Here are some of the key operating principles we hold on to:

  1. The product is front-and-center: we deliver maximum product value on a sprint-by-sprint basis. We welcome changing requirements if they’re in the interest of our common product objectives.
  2. We co-create: a client-supplier relationship in the traditional sense has been the basis of many failed initiatives. We’re on a joint mission with our partners to find, capture and deliver added value.
  3. Dev & Ops are inherently intertwined: development and operations are two sides of the same coin. Gone are the days of finger-pointing from ‘business’ vs ‘IT’. All in it together.
  4. Release early, often, reliably: maximise automated test coverage to increase the frequency and reliability of development, staging and production releases.
  5. We choose progress over process: when dealing with uncertainties, there’s a natural tendency to put things on hold from a managerial point of view. We place full trust in our delivery teams to keep progress going.
  6. We‘re keen on transparency: all tooling and communication is shared with our partners: kanban boards, repositories, communication channels, etc. We’ll surely mess up at some point, you’ll be the first to know.
  7. Direct feedback lifts up people and product: even though we continuously do peer-to-peer evaluations, we don’t assess individual performance but rather the squad’s achievements as a whole.
  8. We honour great engineering: the ultimate deliverable of a digital product is the codebase that reflects a data structure and defines the user experience. Don’t. Cut. Corners.

Roles and responsibilities

Software development involves many different viewpoints. It’s tempting to branch out roles for various specialty domains and build large teams, introducing overhead and unnecessary alignment. Modern product teams turn this model upside down; it’s more valuable and efficient to work with a small and multidisciplinary squad that’s no bigger than 10 people. Every individual within the squad will carry a delivery mindset to reach a common objective: their squad’s north star. This north star can take many shapes and forms, i.e.: improving scalability and uptime, increasing conversion, new feature development etc. These objectives will evolve over time as your product evolves.

We created a lightweight model with only a few roles and responsibilities that reflect this philosophy.

  • Product manager: takes end-to-end ownership over the product development progress. Motivates the team, documents user stories, indicates priorities within each sprint, facilitates the daily standups and sprint demos and orchestrates a sprint retrospective for the squad to continuously learn and improve. A jack of all trades let’s say, with an entrepreneurial drive.
  • Chapter lead: subject matter expert. Assures consistency and training for the whole team across multiple squads. Our current chapters:
- Product design
- Front-end (browser application)
- Back-end (API development)
- Data engineering (infrastructure driven: GCP/AWS/Azure)
  • Delivery team: people from various domains (chapters) that will work together to deliver on their north star objectives.

Granularity of our units of work

The sprint-by-sprint-based operating model requires a paradigm shift in how you measure progress and how you break big objectives down into smaller chunks of work. We define the following units of work:

  • Product strategy: the overall value definition of the product from a user- business- and technology perspective
  • Product roadmap: a fixed bi-weekly meeting where we gather all stakeholders to translate the product strategy into prioritised milestones
  • Product milestones: a multi-month objective to ship a sizeable new feature set into production.
  • Sprints: product milestones will be achieved through a sequence of sprints with continuous, incremental user story delivery.
  • User stories: a sprint consists of individual user stories which describe certain business flows and database relationships.

How this translates to our administrative setup

We choose to organise our entire operations on these principles, including administrative aspects:

  • We choose to be a partner for the whole route. None of these steps in the product development process should be broken up.
  • Offers consist of product milestones and the estimated number of sprints to get there with the predefined involvement of a certain team.
  • Sprint reports are created at the end of each sprint by the product manager. These sprint reports consist of the time involvement of our team members, as well as the delivered user stories.
  • Invoices will be created based on the approved sprint reports.
This whole methodology described here above is rooted in the daily realities that we face with partners of various sizes: scale-ups, SMEs, VCs, corporates, … The same principles stand as long as there’s a product orientation at the very center and an entrepreneurial delivery spirit.

Next up?

In our next blog posts, we’ll dive into technical aspects of our default technical product setup as well as architectural principles.

Missed out on our inaugural blog post? You can find it here.

Care to see our operating model in action in one of our in-depth case studies: