Release-oriented process in Product development

Products are built to solve problems. Building digital products, in collaboration with our partners and clients, is more than solving a problem or achieving great end results — it’s also about how we get there. That’s exactly what we do at Pixelmatters.

To maximize the value of our clients’ products, it is essential to have a product development process that fits the product needs. That’s also one of the main reasons why there’s a constant effort to refine the product development process at Pixelmatters. It’s a pillar of what we consider being essential to achieving a top-notch outcome: meet the requirements set during the product’s value proposition definition while having a close collaboration with our clients, whose involvement and partnership it’s fundamental.

The product development process itself should be defined under a certain context, answer a set of needs and concerns that surrounds the product, guiding us up until the actual release event. This article aims to describe how to shape a product development process in which focus is the release event and how a process of this kind can be applied to a real-world scenario using as an example a product in which Pixelmatters has been involved since the very beginning, Abaca.

But first, it’s required to understand what a release represents in a product development process.

Release mindset applied

Product development is not straightforward. When starting to build a product from scratch, there are a lot of intuitions and ideas on how to solve a problem but until the product reaches the customers, the ones who determine the product’s value, everything is just a concept.

Pursuing a place in the market, especially when this market is a fast-changing environment full of uncertainty, requires a quick reaction to change and fast pace delivery to perform a quick, small and iterative concept validation which will end up being the product value.

Under this context, in which most of the discussions are about the release, deadlines to be met and what scope fits into that timespan, the product development process should be an engine that drives product strategy and helps during the decision-making phase. The release is the core piece of the product development process and that should be crystal clear to all entities throughout every process phase.

What is a Release?

A release is a software package containing a certain amount of scope associated with a version that is distributed upon a certain period and that can be the culmination of multiple iterations. In product development, this scope aims to cover defined needs (functional or non-functional) and, per consequence, to increase the value proposition of a given product, also mentioned as product value.

Having a product development process that focuses on delivering value to customers is crucial for a product to succeed. It’s only possible to evaluate the perception of value in a product when something is shipped. Until that point, it’s only a concept, something that is being built but that cannot be optimized as iterations are necessary to improve the delivery of value in which the change agent is the customer. Reacting to change is triggered by the customers’ feedback — It’s required to ship, listen to feedback and meet the customers’ needs. And the best way of doing it is piece by piece.

Keep it Small & Simple

While continuously looking for concept validation, it’s important to deliver small and quick, allowing a simpler and more straightforward process:

Following the mindset described above, a great product development process looks to optimize the value delivered, while aiming for quick and small quality-driven releases. Each process stage should have a single responsibility, unnecessary steps should be removed and repeated steps should be optimized through the introduction of automated mechanisms. This way it’s possible to maximize profitability and efficiency while reducing risks and costs, as well as removing constraints. Building automation around the deploy process is a good example of this mindset.

Shaping the Process with a Release in mind

Considering the context above, it’s important to understand which stages and main channels are considered throughout the process so that a better balance between the outcomes and motivations can be achieved, always oriented to the release.

Entities & Phases

In our product development process, each main entity involved in the process has a set of responsibilities:

The process is mainly divided into two big phases that relate directly with a specific release:

Other procedures like the roadmap definition, which contains multiple releases ideas, are agnostic to a specific release and per consequence are not within the phases above.

The main goal is to have a set of responsibilities that are shared and recognized by the entities mentioned above, allowing for a collaborative approach in the definition of the product’s strategy.

Collaborative Approach

One thing to keep in mind is that a release is not a feature nor a set of features but an addition to a system. It’s not an isolated piece and there are always unseen dependencies — it’s about integrating and for that, each of the involved entities has a different piece of knowledge that when combined, result in better business decisions.

As an example of why the collaborative approach is so important. The Product entity is not able to define an achievable product roadmap, which represents a set of possible and desirable releases, without understanding the risks and effort involved from both Design and Engineering, having in mind that this procedure involves the understanding between expected product value and estimated costs.

To have efficient communication and collaboration around the release, the best option is to involve all entities in the various phases. Having a single reference throughout the whole process, the release version allows for a smoother collaboration between all entities. The release version is the main reference while discussing deadlines and scope.

Release Timing as Shipping Mechanism

Setting up a release timing works as a time-box that obligates Product, Design, and Engineering to strategically define what’s the feasible scope in order to achieve the proposed milestone. Is this collaborative approach that leads to the discussion of “What’s the minimum piece of scope that’s possible to deliver in order to meaningfully solve this need with the expected quality?” and which ultimately leads to trade-offs to get things done.

And now it’s time to show how we’ve applied the concepts above in Abaca and how the release-oriented process helped us to take this ambitious product off the ground!

A Practical Approach

Abaca is a product in which Pixelmatters has been involved since day zero from a design, development and product strategy standpoint. Abaca is a product owned by Village Capital whose main value proposition is to create a common language between supporters and entrepreneurs in the capital and resources market by easily allowing the companies’ benchmark. Considering the business area in which Abaca operates — the capital and resources market, which is quite a fast-changing environment — reacting quickly to change by releasing small product concepts under an MVP mindset, it was crucial to take the product off the ground. It required a thoughtful product strategy which focus was a continuous release of the product value.

After getting the MVP launched and the team settled in, the desirable time-box for each on-going release was defined in around 4–5 weeks, from which ~3 weeks are mostly dedicated to programming in this specific scenario. Negotiating what goes into a release, if it’s time to take a step back or to go forward with an MVP approach, or simply to get back to the backlog considering the agreed time-box, is key to proceed. This process setup was made in constant agreement with our partners at Village Capital that are responsible for Abaca’s product — their partnership is crucial here as the product development process should fit everyone’s needs!

During the definition of the product development release process, it was necessary to select a set of tools to allow a better product strategy definition based on collected data and feedback, tracking of the defined milestones and clear communication within the team and with the client:

From this point on, the process determined a set of steps that allowed the team to go from the initial release definition, up until the actual live deploy:

A single reference is kept in all phases and tools making it easy to think, discuss, negotiate, and work towards the same goal — deliver value, solve problems.


And that’s basically it! As you can see above, what we call the release-oriented product development process was built to create a common nomenclature, understood by all entities and present in all tools and process phases, therefore removing communication entropy and enhancing the product strategy focus.

Each product has it’s own context, and this process worked great with Abaca… but like any good process, enhancements are iteratively added. It’s on Pixelmatters blood to constantly work towards excellence, we just can’t run away from it. 😅

If you have any scenarios in which you think a similar approach could be applied or if you have any feedback to give, feel free to share your perspective in the comments section below. 👇

Bruno Teixeira
Head of Product