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:

• Faster idealization as the dependencies number should be smaller and placed on top of foundations previously shipped, where the value is already validated. This reduces the number of decisions as there’s less room left for guessing and more data available to stay objective, therefore allowing us to think straight in an area with information overload — something that can be considered as a strong perk;
• Easier to evaluate as feedback is more focused on a single piece and how it integrates with the whole system. Products cannot be tested in isolation;
• The number of change requests per release is most likely to be smaller, which allows a quicker reaction to change, and as a result customers' needs are fulfilled quicker, step by step.

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:

• Product — At a high-level, it mainly consists of ideation, conceptualization, feedback gathering, segment identification, roadmap definition, functional and non-functional requirements conception. During execution, it focuses more on detailed planning, release tracking, risks identification and mitigation, and prioritization;
• Design — Conceptualization, feedback analysis and applicability, user experience, prototyping, core behavioral expectation conception, interface, design to engineering handover documentation, and styleguide;
• Engineering — Programming, infrastructure, technical artifacts and documentation, technical requirements identification and analysis, continuous technical evolution, scalability, monitorization, and reliability.

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

• Conceptualization — Features definition to accommodate users’ needs and product mission;
• Execution — Design and implementation of features and flows.

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:

• ProductBoard — Gather feedback, high-level product management, releases management, and roadmap definition;
• Basecamp — Product thinking discussions and brainstorming, releases negotiation, milestone updates, design presentations, and discussions;
• JIRA — Development management, user stories elaboration, release monitoring, and related metrics.

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:

• Product collects feedback and defines high-level roadmap and corresponding features per release in ProductBoard, starting the conceptualization phase;
• Design and Engineering go through the upcoming releases in ProductBoard to perform risks identification and provide high-level estimates allowing Product to refine upcoming releases based on their inputs;
• Product defines an initial strategy of what a release should be based on the scope of product value and corresponding high-level estimated cost;
• A new To Do list corresponding to a single release is created on Basecamp. Each design task, which should correspond to a card in ProductBoard, is then added to that To Do list;

• Execution phase starts here. The tasks mentioned in the point above will hold design presentations which not only link to the prototypes but also contain meaningful thoughts on why the final result is the one being presented. The main goal is to have the product strategy as a central piece to make the best business decisions;
• Based on the approved designs and business decisions, a new balance of the release expected outcomes is made on top of ProductBoard. Product, Design, and Engineering define a release proposal that is negotiated having in mind the ideal time-box. Once approved, the release proceeds to the programming phase;
• Design exports to Zeplin, tool used as handover to Engineering. Each release version corresponds to a tag on Zeplin making it a piece of cake to filter each release design;
• The release cards are then pushed from ProductBoard to JIRA using integration and sprintable user stories are then created and attached to the main card. Each sprintable user story has a set of requirements and a link to design using a JIRA and Zeplin integration;
• The JIRA release is also automatically created using ProductBoard integration. This is the main monitoring point of the whole release as all user stories are tagged with the corresponding version;
• Once the execution phase is over and there’s a green light to perform the live deploy, a commit is made with a tag attached to it with the corresponding version, therefore triggering the automated pipeline;
• The release is marked as completed on JIRA and ProductBoard, all To-Do lists are archived on Basecamp and in the meanwhile the next release is already in the oven — the cycle starts all over again! 🚀

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.

Conclusion

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. 👇

‍