Product ownership FI

How does Godel take ownership of products?

Firstly, it’s important to understand that product ownership is not an abstract concept. It is a clearly defined set of actions, which Godel software development teams apply to client engagements. Product ownership goes beyond the role of the Product Owner – it is a responsibility of each stakeholder involved in the success of the product at hand.

This set of actions are the team’s priority from the very beginning of a partnership, and they continue to be applied throughout each stage of the software development lifecycle. When Godel forms a partnership, each team member on both “sides” must be honest, transparent and direct. Product ownership is about the actions that underpin this attitude, and how this approach results in delivering products that satisfy end user requirements.

This article describes the actions that Godel teams take to manage and deliver products in client engagements, throughout each stage of delivery. The way these actions are carried out varies because each client is unique, but the process underpinning the methodology remains foundational for Godel. By following these specific approaches, Godel – a nearshore software delivery partner – takes a client’s vision as their own and either shares or completely takes on product ownership.

From the very first day of a partnership, the (Godel and client) team are laser-focused on creating a shared environment for collaboration. The “kick-off” phase is the time in which both parties make introductions, discuss and assign areas of responsibility, and provide the background context of the product at hand. Godel does everything possible to make this time an opportunity for relationship building at the very least every session is conducted via video conferencing, if a business trip to the client’s office isn’t possible.

The client will share with Godel their company vision, business strategy and product roadmap in this phase. As a partner taking product ownership, it’s vital for the Godel team to understand these factors from the beginning. They will set the stage for a constant focus on product and business value when the team is building the product:

Company vision  – what are the values of the organisation? What are its long-term goals? Working together on a highly collaborative basis means Godel must internalise and adapt to the client’s ways of working.

Business strategy  – what are the objectives of the product at hand? Understanding this and how the product fits in with the rest of the business helps add a context-driven mindset to the team’s delivery approach.

Product vision  – where Godel takes an active ownership role. Forming a product vision requires an understanding of the above two factors as well as details on:

  • The business needs in relation to the product.
  • Who the target audience is.
  • What problems the product will solve.

Once these three areas are clearly defined, the Godel team can start building a product backlog with identified features. At this point specific roles and responsibilities will have also been agreed (including who will wear the hat of Product Owner” if that has not been pre-decided), along with an appropriate structure and toolkit for daily collaboration. Something important to remember is that successful teamwork is driven by good direction. In this context the person holding the responsibility of “product owner” must be in control and have a very clear sense of direction which the team can follow from the very beginning.

Elements of product ownership

Godel has worked with around 80 clients over the past 17 years – many of which being long-term ongoing partnerships. To reach its current position it has built and matured practices that are known inside-out across the entire company. In the context of product ownership, this is particularly valuable, as it means a Godel team building a billing product can share a development approach with a team working on an automotive product.

Release planning

The product delivery roadmap is a high-level view of what will be delivered at certain milestones. A release plan takes these guidelines and breaks down in granular detail. The client’s stakeholders must consider the three points detailed above and define what features in the product backlog should be prioritised.

A release plan is structured chronologically, and the pinpoints along the timeline are defined around the wider business timeline. A product mindset always comes back to the constant observation of business and stakeholder context. Godel in the product owner role must always know exactly where specific features rely on other areas of the client business and co-ordinate around these dependencies.

That’s why setting the stage for collaboration in the kick-off phase of product development is so critical. Sometimes, especially in the UK, people are averse to talking with each other – it seems normal to not communicate, and that quietly causes misalignment in product expectations. Stakeholders must be encouraged to communicate with the development team – virtually or face-to-face – as often as required to stay aligned with their portion of the product vision.

Godel takes ownership of release planning by encouraging communication, constantly. There must be a single view of the release timeline; often joining up dots between multiple teams’ own plans and a scattering of external factors is necessary. Product ownership is putting the pieces together into a clear plan. Then, tracking this granular plan in a collaborative manner – Jira or Confluence for example – is an ongoing process.

In client partnerships, Godel taking the reins on ownership of the backlog means a spotlight is immediately placed on business alignment and communication – this is fundamental for the Godel team to work at all, so Godel prioritises it. Our steering of release planning against a unified view of the business timeline means that delivery timelines are not strayed from without clear prior notice.

Sprint planning

The next phase of the product delivery is the sprint plan, which breaks the release plan down into granular “user stories”. For example, if a release plan is on a 3-month timeline, a sprint plan might break down this plan into 6 2-week sprints. Godel takes a product-led approach to sprint planning by deciding how often to release, depending on capacity, feature type and the top priority requirement in the backlog. In the same way, decisions are made on where to release – whether it be in a test or production environment.

Over time Godel owns the delivery process sprint-to-sprint. The product owner works with the client stakeholders before planning sessions, refining the backlog for the team and translating it into user stories for the developers, and ensuring product feedback is a two-way street. The SCRUM and KANBAN frameworks greatly support this.

Designing a product

Godel’s Business Analysts, Product Owners and Front-end developers, amongst the wider team, love to get involved with product design. Thanks to Godel’s long-standing clients, working with mature practices, Godel teams work with clients’ UX/UI teams to build a shared understanding of product design. We understand how to build a user experience following product-specific standards and have built a solid knowledge base of building re-usable UI components.

The Godel BA / Product Owner (depending on team setup and placement of product ownership) is responsible for understanding the bigger picture of the client, and how the product at hand integrates with their wider company. Then, with our historical product delivery knowledge, we can visualise what a product “could be” and share this potential with the client. Godel does this by examining the user experience,

Product quality

Quality isn’t just about the testing strategies employed upon the product. It is embedding the mindset of quality into the whole ecosystem of the SDLC to ensure all aspects of it are bringing value. So, we build this ecosystem in a way that balances quality and cost, depending on the product and the problem it needs to solve.

The quality assurance approach considers the “real-life” product users – Godel works with clients to organise a “user acceptance testing” process that brings the end-users in. Using an established product context, the Godel team can prepare scenarios for this process and then collaborate closely with the client to cover any gaps with additional exploration. Holding meetings, providing technical support for users and creating guides are all part of the approach.

At Godel, we usually encourage UAT to be carried out before the MVP is released. This adds an often-needed layer of scenario testing to uncover unexpected issues before going to market.

Godel’s overall quality approach encourages clients to share ownership. We need to ensure that the foundational context set at the kick-off phase is built upon as the relationship progresses. This requires constant communication. It is part of Godel’s approach to conduct regular peer-reviews. Here, Godel adopts a “reverse augmentation” approach where client developers are embedded into the Godel product team – encouraging a closer relationship and boosting knowledge transfer.

As a partnership begins to form it can be realised that team skills need to evolve with the needs of the product. For example, we may realise that DevOps skills are required. With a close partnership, we can identify this requirement early and resolve it by either adding additional skills to the team or even upskilling a member, depending on the context.

Supporting product delivery

Development teams must have a level of technical prowess that can meet the delivery requirements of a product. Beyond this, however, they must be able to build upon their soft skills too – in a product mindset context, this is just as important as the tech.

To facilitate this Godel has dedicated groups of senior employees – teams called “Functions” that work across its technical divisions (.NET, Java etc) to support individual and team skills.


These functions are involved in the personal development of Godel teams. Consultancy helps guide technical direction when a roadblock arises in a client project, which helps teams learn new paths to success. Education constantly encourages employees to pursue learning with organised internal events, conferences and virtual resources. Talent acquisition is part of our selective hiring process, ensuring that we bring the best skills and qualities on board depending on the context. For junior and senior staff alike, Onboarding and talent management are functions that provide mentoring professional growth. All these additional support frameworks help Godel teams develop skills that are necessary to work with clients on delivering valuable products.

Aspects of great product ownership


Sometimes delivering hard truths to a client is necessary, albeit difficult. If honest opinions aren’t expressed by the Godel team, delivering value is side-lined. By choosing to partner with Godel clients are bringing additional expertise into their capability. As mentioned, we have built foundational cross-domain knowledge over the years that helps us recognise good and bad practice. Godel teams possess a slightly different perspective of product roadmap compared to the client – sometimes the client loses sight of end user needs against internal expectations. It is always the Godel team’s collective responsibility to not be afraid to share honest feedback and advice.

Embedding Godel

For a product mindset to activate the Godel team must be in the same business context as the client. We need to be a single team only separated by short geographical distance. Godel partnerships don’t work when it’s just “work”. The team must be part of core strategic decision-making when it comes to the product, from technical and architectural perspectives. Collaboration can only be achieved by both parties being fully committed to it. Godel invests in communication resources such as HD video conferencing suites and virtual meeting software to make this work. Mutually, partnerships dive into understanding each other’s’ working practices, cultures and individual personalities to bring the best out of their partnerships.

In many cases Godel teams starting new partnerships will dive into learning about their client’s market. For example, Crunch Accounting is one of Godel’s clients – their products must adhere to complex accounting law. So, the Godel team began the partnership by learning about this. Over the years and partnership-to-partnership, clients benefit from Godel teams that have experience across various domains. Introducing them to decision-making and encouraging them to innovate provides a fresh direction for product delivery.


In order to deliver great products, teams need to hone their self-certainty and possess a high level of innovative energy. This is not always something that comes naturally; it must be encouraged. Otherwise, teams will struggle to become independent and autonomous. This leads to inhibited creativity, because teams are unsure of their environment, uncomfortable to put forward ideas and constricted from open thinking. Without transparency and clarity teams find themselves fighting to understand what’s coming next rather than being able to experiment outside set requirements.

Establishing a truly safe environment team requires Godel to build real partnerships – not supplier relationships – with its clients. Stakeholders on both sides must understand why it is important to recognise that mistakes (the “fail fast” concept) are fine – it’s because they are in the direction of learning and progress in making a product better.

Roles in the Godel team exist to facilitate this. The Agile Delivery Co-ordinator is there from all perspectives – communicating with the client and feeding back to the team, but always encouraging direct conversation between team members. They will recognise when a team is constrained as outlined above and can bring in necessary support from Godel Functions or escalate with the client to address issues.

SCRUM masters are dedicated to facilitating safe environments for teams to work in – they are specifically trained in removing any blockers to teamwork

The Product Owner, of course, must hold the reins on product direction. This absolutely factors in creativity – otherwise, cookie-cutter products are all we can expect. They bring teams together, literally during planning sessions and retrospectives, and keep the spotlight on delivery which encourages a focus on finding new approaches rather than just following direction.

A fine balance must be struck between under- and over-confidence. Being too sure of your viewpoint can cause others’ views to be left behind. To address this we must look back to the first point of honesty – this is a great example of a difficult situation that must be addressed. Teams must feel comfortable and safe enough to speak out about issues like this. By supporting their personal development and encouraging product ownership – pride and prioritisation of the product’s success – teams will be honest about what is necessary to deliver a great product.

Read the first part of this series: The Product Mindset Philosophy.