Optimizing Digital Product Development: Strategies for an Effective Workflow (I)

‍

In digital product development, the ability to organize work, define responsibilities, and maintain effective tracking not only marks the difference between success and failure but also determines the efficiency and productivity of any product team. The key to navigating the complex lifecycle of product development lies in the strategic division of categories according to task type and the implementation of a simple yet robust and flexible workflow (like bamboo). This methodology not only facilitates the efficient handling of various emerging needs and problems but also ensures the correct implementation of solutions and the maintenance of a roadmap perfectly aligned with the company's strategy.

In this post, I will explain how structuring and categorizing work from the most strategic to the most tactical dimension can transform the way teams operate, promoting a cohesive and highly efficient work environment. In my daily work, I have managed to divide the dimensions of product development in the following way to organize an appropriate workflow and divide responsibilities:

‍

1. Problems or Needs

This is the origin of everything, whether it is a request from the business team, an observation you identify in users, a savings request, or an innovative idea you believe will be the next big hit for the company. Regardless of the origin, we need to understand what the problem or need is, and before defining the solution, we need to ask ourselves the same questions: What, Who, Where, When, and Why.

In this stage, it is very important to question the "why," and often, we will have several possible explanations. Don’t worry, we are here to explore! Write them all down and create different hypotheses. If you do this, numerous ideas for validating or rejecting them will start to emerge. This is where deep analysis comes into play. Some ideas will be discarded, while others will sound plausible. It's time to select the ideas that you believe can work to solve that problem or need. It's time to move on to building the solutions.

‍

2. Solutions (or what we will call Features)

Now it’s time to think about what the solution is, its objective, its scope, define its target audience, the KPIs you will use to measure its impact, and something very important: its profitability and urgency. These last two points will help you later to manage the multitude of features that flood your backlog and are waiting to be placed somewhere on the roadmap.

ProfitabilityHere comes the most complex part, and you can spend hours on it if you don’t know how far to go. Your ultimate goal is to know the ROI and the expected payback, and to do this, you have to measure: cost and benefit (income or savings).

BenefitI always start by measuring the benefit. Depending on each feature, you need to establish your current state. For example, for a feature to create a landing page to improve SEO, I ask myself: How much traffic is currently coming from this type of search? How do I rank? What conversion does this type of traffic have? What value (in money) does each conversion of this type have? This will help you have a starting point and assess the problem’s dimension.

From this starting point, it’s time for assumptions: What do you intend to do? How do you think you will improve those KPIs? When do you expect to see the impact? Is it immediate or medium-long term? Is the result linear or exponential? Here, it will depend on your and your colleagues’ knowledge to be as accurate as possible (remember your hypotheses), but a piece of advice, make two scenarios: one negative and one positive, and stay in the middle leaning towards the lower end. We tend to be too positive. Once you have the expected estimates, compare them to what would happen if you stay in the current situation (doing nothing) and translate this difference into money.

CostNow comes the cost part, which is not simple either, but it depends on your team’s knowledge, previous experience, and the degree of uncertainty. Calculate costs for each specialized team by day (I prefer not to do it by hours) or by story points (calculate your team’s average velocity per sprint). Sit down with your team with the high-level scope and make a high-level estimate (DO NOT OBSESS) of each development part. Add a margin for unforeseen events, lack of knowledge, and underestimation of your team’s effort.

‍

ROI and Payback

‍Now you have it easy, just a couple of formulas and you’re done:

• ROI = (Annual Revenue - Annual Cost) / Annual Cost
• Payback = Initial Cost / Revenue

I usually calculate it by months, but you can do it by years or days, whatever suits you best. Be careful with this calculation; sometimes it’s not that simple. If the feature’s impact is immediate and you’ll perceive benefits from the start, you can simplify it. If the benefits will come progressively and grow exponentially, remember that payback is the point when the initial investment and maintenance cost are exceeded by the accumulated generated revenue.

‍

Urgency

‍Urgency is usually easy to establish. Make a 1 to 5 scale to standardize this metric when comparing it with other features, and ask yourself these questions: What happens if I don’t do it now? What happens if I wait? Does the market need it urgently, or can it wait? Does your company need it urgently? Does it create dependencies with other business initiatives? Are you the first to launch it in the market? Does it matter?

These questions and others can help establish urgency. Standardize it by thinking about the most urgent situation for the maximum level (5) and the least urgent for the minimum level (1).

‍

Prioritizing the Roadmap

‍With everything about your potential solution:

• Context of the problem or need
• Feature description
• Objective
• Target audience
• Profitability
• Urgency

It’s time to take it to your roadmap and prioritize it. I’ve discussed this in previous posts like Mastering Product Prioritization: Techniques to Maximize Value. But continuing with this financial view of your backlog, a good way to bring order to chaos is to create a small impact formula to objectively compare many features. I use Jira Atlassian’s Product Discovery, which allows me to establish a relative impact score for all features in my backlog, giving weight as follows:

Positive inputs:

• 40% Urgency
• 60% ROI

Negative inputs:

• 100% Payback

This generates relative scores based on my entire backlog, where higher urgency and ROI but lower payback have more impact scores.

‍

3. Epics

Features are a very effective way to understand which high-level initiatives you will work on, explain them to management, and make everyone outside your area understand. But epics, for me, are the way to transfer them to the teams and group large sets of tasks or user stories. Normally, I don’t create more than one epic per feature, but when a feature is too large for one sprint or has several aspects to design and develop, it’s ideal to create multiple epics. Once the epics are created with the team, my personal preference is for the leader of each team to detail the technical aspects.

‍

4. Tasks and User Stories (US)

Tasks and user stories, once refined, estimated, and prepared, are those that, following the same order, the team prioritizes for execution. In the planning sessions, you’ll realize if they can complete it in one sprint or if you need to break it into blocks to have part of the feature ready to deliver in each sprint. Delegate to your team, let them own their work, help prioritize as a PO, ask many questions, and most importantly, trust them. If you can transfer the main objective to them and make it theirs, they won’t fail you.

‍

Conclusion

After breaking down the labyrinth that is digital product development, I conclude that, although I sometimes feel like a juggler trying to keep a hundred balls named "tasks," "epics," and "features" in the air, there is a method to this madness. By dividing the work, establishing clear flows, and assigning each bit of responsibility, I have not only managed to keep the balls from falling but also choreographed a rather beautiful dance. Organizing this chaos is part of the fun. Who would have thought being a digital orchestra conductor could be so entertaining?

For today, I think that's enough. I would have liked to talk about the workflow for each, but that will be for a second installment of Optimizing Digital Product Development: Strategies for an Effective Workflow. This is easy to explain but hard to implement, so don’t worry. I’m sure you’ll be capable, or better yet, find your method and share it with me. If you learn, we all learn.

‍