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

‍

In the previous article on Strategies for an Effective Workflow (I), I discussed how dividing work into categories and responsibilities helps define a global workflow to improve efficiency in your digital product development. Today, I'll talk about how you can design that workflow and the risks to consider to achieve it successfully. Let's get started!

‍

How to Design an Effective Workflow?

First, we need to understand what types of requests the team receives, whether they are problems, tasks, incidents, initiatives, or inquiries. It's also important to know who is making these requests and how they are made. This understanding is crucial before we start outlining anything; otherwise, we risk designing a solution that doesn't address existing needs, leading to inevitable failure. Talk to your stakeholders and your team, understand their needs and problems. If you already have a backlog, read it in detail, and immerse yourself in it. Ask yourself some questions: Is information missing, or is it detailed? Are they general ideas or specific requests? Are they from internal or external users? What profile do your stakeholders have?

‍

This analysis will help you understand the situation and the starting point. Not all companies are the same, and much depends on the culture and the type of stakeholders in your environment. Knowing how the demand is structured will help you clearly define your team's objective and what is expected of them. This is a key first step in designing the workflow.

‍

Designing the Workflow

Now it's time to think about how each type of request is resolved. Take a representative example and consider what needs to be done from the moment it reaches the team until it is resolved. Drawing a flowchart of the actions will help significantly. Create something very detailed, outlining each step of the task. Here's an example:

‍

‍

‍

‍

At each step, pause and ask yourself several questions: Who is responsible? What exactly do they need to do? Is another person or department needed? When is it supposed to be completed? What needs to be done next? Gradually, you will add steps and concrete actions, forming a logical series until you complete the entire chain.

‍

Analyze if each action you note is generalizable, i.e., is it common to all tasks or specific to this one? Write down only the general actions that all tasks share. This is not something you can do alone; sit with the person responsible for each action and design a complete and detailed flow.

‍

Once you have painted the complete flow of actions, group them into different states or phases. Put yourself in the shoes of the person who needs to see these states and for what purpose: Do you want to track it yourself? Is it for your team to know when to perform something? Is it to show stakeholders the progress of their request? Depending on the goal, there will be more or fewer states. My advice is to follow the "less is more" principle: build something simple to understand but useful. Typically, if it’s for external people, very general states are sufficient. For the team, group actions by concrete objectives. For example, in testing a new feature, there are many actions (integration tests, load tests, performance review, design, functionality, etc.), but all these steps have the same goal and the same person responsible, so you can group them into a single state called "Testing."

‍

When you finish defining the states, validate that all requests go through these states or most of them (yes, they can skip a state if it's unnecessary), and you will get a list of common states. Here's an example:

‍

‍

‍

Now, the final part is to establish the flow between states, i.e., how a state transitions to another based on the final result. Use the flow of actions you previously created to apply concrete cases and extract a general rule. For example, a task in the "UAT" state can move to "Pending Release" if the tests are successful, or back to "To Do" if the tests fail. This way, you’ll get a clear and structured workflow, something like this:

‍

‍

The result is a set of grouped actions into general states applicable to all the team's work. This helps you understand where any task is in the process, who is responsible, and how much remains to complete it in an easy and intuitive manner. With the workflow designed, you are ready to share it with all involved and implement it. Good luck!

‍

Risks in Designing a Workflow

Even though you've learned how to design a good workflow, there are certain considerations to keep in mind to ensure it's 100% effective and successfully implemented. Here are some key risks:

‍

Beware of Complexity!

‍As mentioned, simplicity is crucial. "Less is more." Don’t try to create anything overly complicated. Make a flow that anyone can understand. Share it with your team or stakeholders. Try explaining it to someone who has no idea and ensure they understand it quickly. If not, rethink it.

‍

Avoid Rigidity

‍Allow states to move freely instead of creating something rigid that can’t adapt to exceptions or unforeseen situations. If not, your team will waste time moving tasks between states without adding value, and you won't be able to adapt to new situations. Remember, a flow is a framework to facilitate work, not a hindrance.

‍

Don’t Do It Alone

‍Involve all stakeholders in designing the workflow. Otherwise, you might omit important processes or face significant resistance to change when implementing it. Resistance to change is common and natural. By collaborating in the design, you’ll get more commitment and valuable contributions you hadn't considered.

‍

Establish Communication Channels

‍A workflow’s main goal is to facilitate communication between internal and external teams. Without setting contact points and communication methods, you won’t achieve good collaboration or smooth process advancement. Use appropriate tools like Jira, Asana, or Notion to visualize states, leave comments, assign tasks, and have a global view.

‍

Think Long-Term

‍Consider team dependencies, bottlenecks, increasing requests, or future team growth. Is it easily scalable? If not, reconsider it.

‍

Does It Add Value?

‍A workflow should help the team in their daily tasks and unify stakeholder expectations. If you don’t consider workload, team well-being, and business objectives, it can easily lead to burnout, reduce morale, and affect productivity, generating the opposite effect of what you desire.

‍

We could delve much deeper, but these are the first steps to creating a simple and effective workflow. I hope it has been as useful to you as it has been for me to explain it. Remember, workflows are living organisms that evolve and change, so implement them, analyze their effectiveness with the teams, and modify them as needed to ensure they are useful, simple, and valuable. Continuous learning is what will lead you to success.

‍