Brief Intro

Why does it take so long to go from an idea to a feature release? It can feel like
an entire app could have been developed in the time it takes to develop just one
small feature. And why is it so difficult to provide clear explanations about
delays?
What challenges prevent teams from meeting deadlines, and can a product owner help
address these issues?

In this article, I’ll explore these questions and discuss potential solutions,
drawing on the processes we’ve developed within the product department at Exante.
Spoiler: this article is not a step-by-step guide. Each company’s journey is
unique, and what works for us may not necessarily work for you.

Where’s the Catch?

Many people contribute to the development of a feature/product, but communication
between them is often inefficient or simply nonexistent. In my opinion, this is the
root of the problem. Consider these scenarios:

The developed product doesn’t meet the requirements because there were no clear
requirements, they weren’t clarified, or they changed mid-process without proper
documentation.

A design was approved by the client, but the implementation turned out
significantly different because developers later reported that the design wasn’t
feasible.

The same feature behaves differently across projects because there was no
synchronisation in implementation or fixed requirements.

If you’ve experienced any of these situations, we’re likely facing the same
challenge.

In all these cases, the core issues are inadequate communication and a lack of
documented discussion results. At Exante, we tackle these challenges by
establishing structured processes where the product owner plays the central role.

The Role of the Product Owner in the Team

In addition to taking part in individual projects, Exante’s product owners form a
separate team of product owners for all projects.

Why is a central team necessary? While each project has its own product owner, many
projects share common functionality. Shared features need to be coordinated among
the product owners to avoid inconsistencies in implementation. For example,
consider the request, "We want to add a button to the trading terminal." This
addition would affect all trading terminals, which span three different projects,
each managed by a different product owner.

This approach helps us to:

Consistently implement shared functionality across all interfaces.

Ensure all projects adhere to a common feature selection strategy.

Leverage collective insights to solve emerging issues.

Build more efficient processes.

Processes and the Problems They Solve

The diagram below illustrates the process for developing a feature/product. It
remains the same across all innovations, regardless of size, complexity, or other
characteristics.

The starting point is the feature request. Where does it come from?

From a hypothesis proposed by the product owner or the product department aimed at
addressing a user problem.

From the product owner's insights on market-required functions.

From findings obtained through reference analyses.

From a feature request submitted by internal employees or entire departments.

Discovery Phase
The discovery phase is divided into several stages:

Basic Discovery
When a feature request is submitted, it enters the basic discovery phase. This
stage involves analysing global factors, such as:

Aligning the request with business goals. The request’s goals and objectives are
assessed against the company’s strategic goals. Many ideas may be discarded at this
stage, as even the best ideas are meaningless if they don’t align with the
company’s overall strategy.

Evaluating user usefulness. This step assesses the feature's value to users, using
the JTBD (Jobs to Be Done) method alongside interviews and surveys of the target
audience.

Market demand assessment. This stage evaluates whether the feature will benefit a
large number of users by addressing questions like: “How many users face the
problem this feature aims to solve?” It also includes competitor analysis and
reviews of overall market trends.

Economic feasibility evaluation. Finally, we analyse the costs and benefits of

implementing the feature. This answers the critical question: “Is the potential
usefulness worth the resources required?” For example, dedicating a month to
developing a button that only two users will use is unlikely to be rational.

If, at the end of this process, the product owner concludes, “Yes, we need this,”
the feature is submitted for approval by the top management. From there, it can
follow three possible paths: approval, a full and irreversible rejection, or it
goes on the “to do later” list.

What problems does this detailed analysis address?

Transparency in decision-making.

Reduction in the number of useless features (minimising time spent on features that
won’t provide value or be used.).

Full Discovery
If the feature is approved, it advances to the full discovery stage. At this stage,
the product owner:

Defines the overall concept, including user stories and potential use cases.
Develops requirements (functional and non-functional).

Collaborates with the design to prepare the design.

Creates detailed technical specifications for both backend and frontend.

Challenges at This Stage

The design presented to the client might not be approved, requiring multiple
adjustments.

Solution: Fix all the required adjustments. We create the design (or preferably a
dynamic prototype for better flow visualisation), show it to the client, discuss
the desired improvements in detail, and record the discussion outcomes in the
meeting agenda and the feature chat (or an alternative discussion channel). The key
is to make a note of all of the requirements and arrive at the next discussion with
specific revisions and well-supported proposals. This approach typically reduces
the number of final approval cycles to 2-3.

The development requirements may prove unfeasible or result in an implementation

that doesn’t meet expectations.

Solution: Engage developers early in the process. Once the design is complete
(preferably as a dynamic prototype for better clarity) and the flow is defined,
hold discussions with key developers (e.g., frontend and backend tech leads). It’s
not necessary to involve everyone; tech leads with relevant competencies are
sufficient. During these discussions, we assess the implementation feasibility and
document the results. If conceptual changes arise, we reconvene with developers to
discuss the potential impacts and refine the plan accordingly.

The outcome of this stage includes the following key deliverables:

Feature product description,

Technical specifications,

Mockups,

Supporting documents for better understanding (maps, dynamic prototypes,

references, etc.).

What problems does this approach address?

Detailed documentation for all participants. A detailed description of behaviour

and implementation, agreed upon by all participants, ensures that the documentation
can be reused for similar projects and serves as a reference if any questions
arise. It also helps reduce requests from other departments, such as “How does this
work?”

Fewer surprises during the delivery phase. Detailed preparation and collaboration
with other departments ensure that everyone is aligned by the time planning begins.
While minor issues may still arise during development, there will be significantly
fewer surprises.

More accurate delivery timelines.

All artifacts are included in the initiative (or deliverables or epic, depending on
the feature's size), and they are handed over only in this complete form for
development planning.

Delivery Phase
Once all necessary documentation is prepared, the development planning process
begins. The first step is to create epics for development within the initiative
created during the discovery phase. There may be one or multiple epics, depending
on how the task needs to be broken down based on factors like plans, resources,
workload, and other considerations.

The development planning process includes:

Requirement analysis. The product owner and team discuss the final requirements and
address any issues related to workflows, corner cases, integrations, etc. This
phase is crucial for gaining a clear understanding and providing a preliminary
estimate of development timelines.

Backend work planning (if necessary).

Documenting the agreements on plans. The product owner documents all plans in the
initiative, which is then reflected in the roadmap.

After these steps, the development process begins.

What Role Does the Product Owner Play Throughout the Process?

Communication with development and QA teams regarding any questions that might
emerge during the process.

Updating documentation after clarifications.

Stage-by-stage acceptance to ensure that the implementation aligns with the

requirements.

Accepting the final product.

Problems That Arise at This Stage

During requirement discussions, everyone agrees that "everything is clear," but the
final implementation ends up not matching the requirements (due to
misunderstandings, misreading, etc.).

Solution: Implement acceptance checks at each stage. Since it’s difficult to

anticipate discrepancies, we track progress dynamically and address any issues as
they arise.

Once the feature is released to production, the development team moves on to the
next feature, while product owners focus on gathering feedback from the newly
released feature. However, handling feedback within the product department is a
separate topic, which will be covered in the next article.