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.
Curtain Call?
Almost.
In conclusion, I want to highlight that in any software company, there are complex processes involving many participants, which inevitably leads to challenges—such as those related to requirements and communication, as discussed above. The goal isn’t to assign blame or reward the right people, but to structure the process in a way that minimises gaps and inefficiencies. While this may seem like common sense, it’s important to emphasise.
And now, the curtain falls.
P.S. What challenges do you face during feature implementation, and how do you address them?