Blog

An operating model that reflects the day-to-day activities of product delivery

Methodology
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 product delivery.

We offer digital product development services to industry partners with big dreams for (knowledge) domain. In order to set any partnership up for success, it's crucial to define a joint responsibility model with a limited set of roles, a proper underlying talent model, a flexible delivery model and a transparent administrative model. Let's unpack...

Roles and responsibilities


In product development, there's only a single measurement of success: product progress. To facilitate this, there needs to be a continuous product value delivery stream, driven by a dedicated product team working along various subject matter dimensions.

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. Every individual within the team will carry a delivery mindset to reach a common objective: their 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 owner: embodies specific industry knowledge (usually on client side)
  • Product manager: makes key decisions on product roadmap and the functional description of the underlying user stories within a sprint. A jack of all trades with an entrepreneurial drive.
  • Chapter lead: subject matter expert. Assures consistency and training across multiple teams. Keeps a birds-eye view.
  • Delivery team: people from various domains (chapters) that will work together to deliver on the product roadmap objectives. Specific product involvement.

Our current chapters consist of the following subject matter domains:

  • Product strategy / business development: doing the right things
  • Product design: turning the defined strategy into clickable prototypes
  • Software engineering: front-end, back-end and embedded engineering
  • Data engineering: data processing, structuring and extracting product value
  • Growth (marketing): becoming top of mind with the desired target audience
  • Customer success: a frictionless onboarding and customer experience

We step away from the notion of a 'product CTO'. Instead we prefer to foresee in-depth domain expertise according to the various chapters we define. It's the key responsibility of the product manager to bring the right people together at the right time.

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.

We continue to foster a culture of engineering excellence, with respect for the subtleties of the craft. 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
The traditional waterfall model based on deadlines has rightfully been set aside and replaced with an operating model based on 'agile' principles. However, this leaves every organisation (or every product team) 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.

Granular 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 definition: 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 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: https://panenco.com/cleverkids
Don't hesitate to reach out to hello@panenco.com in case of questions.