Seven questions you might have about going “all in” on Product Delivery - ProductDock

Seven questions you might have about going “all in” on Product Delivery

by Stefan Siprell 01/18/2023

Introduction

Product-based delivery sounds like an excellent approach to delivering IT value to customer-facing systems, right? We at ProductDock wholeheartedly agree.

It matches remote work nicely, as the approach lets you engage teams and make them accountable for their actions. Also, with modern SaaS providers, you can quickly mesh applications from various services to promptly churn out the first value-bringing applications.

Enabling your team to work to its fullest potential and leverage all the new IT capabilities requires organizations to step back from traditional approaches and embrace new tools to ensure their budget is spent wisely.

Switching to a product mindset will require a leap of faith. Often organizations will only take small and tentative steps toward a new mode and end up disappointed that the results are not promising.

We have collected the most common obstacles we have encountered with our customers and would like to share them with you to give you the confidence and courage to unleash your ITs potential.

Questions

Why should I care about product development?

In a well-run, product-oriented company, waste is reduced to an absolute minimum.

Waste can be created at any part, starting from idea inception and budgeting down to operating the solution for the customers – waste does not just incur during the development of the code itself. By the holistic approach of giving the entire problem to a self-contained team, you can achieve the following:

  • Higher responsiveness in the delivery: Agile and DevOps are best-in-class practices incorporated into Agile Development projects to enhance software delivery velocity, service dependability, and stakeholder ownership. In a product, the DevOps lifecycle covers all aspects, from internal stakeholders to the collection of the actual customer feedback – reducing waste over the entire lifecycle as you no longer need to anticipate potential issues of a non-existing software solution.
  • Have a constant ideation process: With market insights, product managers can drive and support ideation and evaluate ideas for the market fit. Including IT experts like architects, engineers, data scientists, and UX designers sooner in the ideation process increases IT ownership of business-enabling ideas. As the entire team has all the capabilities and competencies to ideate new solutions to new problems, ideation no longer needs to occur only once at the beginning but becomes a constant and repeated activity. By revisiting old topics with fresh insights, you can solve problems efficiently ad-hoc and eliminate the need to predetermine capacities up-front.
  • Improve the customer experience: A product-centered company believes that a good customer experience generates and maintains a successful business outcome. Products are tested in focus groups to ensure they suit client demands. The team can seamlessly move back and forth between ideation, hypothesis validation, and releasing new features until the solution matches or exceeds the required customer experience.

How ProductDock can assist: Using our ProductScore, an in-house development mechanism, we can give you precise feedback on how well you are reaping the benefits from the product-based approach and develop specific action plans, insights, and training to reach the next level.

We are already doing agile development – how is product development different?

A product-centric delivery paradigm requires focusing on long-term objectives rather than short-term wins. The teams here prioritize the project’s result above timetables and money. The aim is to increase ROI. Product mindset concepts concentrate on establishing a great customer experience, constructing a roadmap with regular releases, and producing the correct product.

On the other hand, the project mentality is a way of doing things in a specific time frame. For many firms, project mentality implies recruiting teams to fulfill timelines, budgets, and other limitations. While a project could be completed within the constraints established, it is typically an invaluable product due to the emphasis on task management – a key distinction between project and product management.

Any improvements from previous investments into agile delivery retain or even increase their value and will help your organization lift all of the product-based potentials:

  • We can now gather regular user and customer input early on, which helps us verify our ideas and alter our strategies, which raises the likelihood of generating a product with good UX and features.
  • We can now deploy new products and features faster due to greater communication with cross-functional development teams, moving away from written documentation, and adopting approaches like user stories to decrease overhead.
  • Agile development approaches like emergent design, test-driven development, and continuous integration have enhanced our product quality enabling us to react swiftly and simply to consumer input.
  • The product folks are no longer entirely responsible for creating the requirements. Instead, the whole team actively assists in improving the product backlog and capturing new product backlog items. This kind of organization increases requirements quality, develops group ownership, and leads to better products.
  • Better visibility of development progress allows for early corrections: A functional program instead of a thorough Gantt chart-based project plan shows progress. This kind of program reduces the possibility of late discovery of product delays or improperly deployed features.
  • Frequent collaborative workshops like sprint reviews have improved stakeholder and development team alignment. The workshops foster understanding and commitment: Asking people for their opinions and including them in the product decision-making process enhances their support.

How ProductDock can assist: We include Agile Coaches in our set-ups to help you hone your agile skills to extract more value from the product-based approach.

Is it not too expensive to have a long-term team working the whole time?

Projects are a risky business. They are expensive, hard to set up, and have no guarantee of success. An often response is over-reliance on risk mitigation, i.e., breaking down tasks and risks, instead of building up value, which leads to thinking that more is better:

It’s better to have many features: Adding features increases value for consumers, whereas removing them reduces value. Products become complicated because of this mentality. There are many buttons and knobs in automobiles, remote controls, and computers, and even the basic toaster today has instructions and LCD screens. Often these features are added at the beginning, thinking that the more, the better. Without user feedback upfront, you cannot judge what is required.

It’s better to have a large team: As projects are limited in time, and the exploitation/run phase is often much longer, the reaction is often to make the team a bit bigger to have more “delivery resources.” Larger teams will lead to more overhead and more latency. Also, new groups of people need time to become performing teams. Knowledge needs to be collected for a new team and documented for a decommissioned team, leading to higher ramp-up and ramp-down costs.

It’s better to have extra preparation: The final fear of working with temporary teams on long-term problems is thinking that it is best to develop the solution as much as possible before too many people depend on you and wait for guidance. On the one hand, this might be a sign of not enough trust in the team’s capabilities, but on the other hand, it could be a sign that the team is too large – see above. By making any preparation beforehand, you rob the team of this option later during the delivery. If this is overdone, the team will no longer be accountable.

Product development does not require big-bang releases. Instead, small teams can work over long periods. All of the knowledge is retained, and efficiency gains compound over time. You should refrain from predefining the solution to anticipated problems but allow the team to discover issues and define solutions during the delivery with customer feedback. The same goes for governance: describe your basic guard rails for compliance and governance to achieve consistency between your projects and let the team deal with the upcoming issues in a pragmatic and adaptative approach.

How ProductDock can assist: At the beginning of every undertaking, we will determine the problem and business case before we start collaborating. We have several workshop formats to help uncover the problem and create an alignment in your organization. Also, with our periodic check-ins, we ensure that you stay focused on problem-solving. Finally, we can offer you fully x-functional teams by working with our Nearshore Development centers. We ensure that you can work with a long-term team at sustainable rates.

I already know what has to be done in the next three years – why should I ignore this?

New POs are eager to delight their customers, end-users, and other stakeholders. An item (or ‘item’) is a feature, user narrative, or need. The asker explains why it’s vital and must be placed in the product backlog. The new PO drops it to the bottom of the list. Initially, this works well, and the customer/end-user/stakeholder is pleased that their request has been put into the Product Backlog. But there’s a concern lurking under the surface.

A backlog binds the POs and their teams’ capacity during development. If you have a backlog of 100 items and need to analyze each item for 3 minutes to prioritize, prune, or determine the next sprint, your PO will require 5 hours of uninterrupted work just to process old ideas. Often this will lead to POs focusing on the newest / well-known items and letting the rot of abandoned ideas grow even further.

Also, a backlog projects false certainty. If you have 100 items in your backlog, and each item requires four days to be analyzed, developed, tested, and shipped, you have a backlog for at least two years of development. If you were to implement the backlog, you would be ignoring customer feedback for the next two years and would be anything but agile.

A backlog often grows beyond control if outside parties contribute ideas without validation. Not only does the too-large backlog suffocate your attempts to become agile, but it also robs your team of accountability. The team needs to be able to define its hypothesis and conduct its validations if you want it to focus on customer success and not just on internal tasks.

Finally, by over-defining your requirements, you make it much harder to pick convenient cloud SaaS offerings and steer the team towards custom developments, as no ready software will be able to cover all anticipated – but unproven – requirements. It is usually much more effective to start with a market leader with minimal configuration and integration in a real-world scenario and work from there.

How ProductDock can assist: With us, you can skip the typical preparation phase, i.e., the requirement gathering and structuring phase. We have a complete menu of various activities to identify your problem, sketch solutions, develop MVPs and align with your customers/stakeholders. Our activities are workshop-based to allow collaboration and alignment between all involved parties. They will always lead to tangible outcomes, most of them in the form of a functioning IT solution – instead of endless word documents and excel lists.

We do not just provide support at the beginning. Our consultants will also conduct bimonthly sessions with you to identify anti-patterns like “Too Large Backlogs” and will actively help you resolve these issues. At the same time, we will develop the solution with you.

Don’t I lose control when the team makes all the decisions?

Software initiatives are seldom predictable. Initial needs may be difficult to execute or have an incorrect strategy. On top of that, people may be illogical under duress. Many projects fail because project managers fail to understand and account for these underlying elements.

In reality, failure is quite probable at many phases of a project. Therefore project managers’ desire to create tactics to prevent failure looks sensible. They feel that the more predictable and tidy things are, the less likely their initiative will fail. An outline of the work necessary to finish the project sounds like a decent place to start.

And thus, when project managers seek certainty, they try to control the variables that may impact it. The individuals surrounding them tend to get the greatest attention—those responsible for delivering the project’s deliverables. Suddenly, the project team is constrained, and management promotes conformity. They focus the team’s efforts on achieving a predetermined result.

The main lesson for project managers seeking transformation is cultivating the correct mentality for themselves and others. Encourage increased cooperation, individual accountability, and team self-organization. Stop fussing about planning and procedures and start leading initiatives.

All mentioned above does not, however, imply that product development is a free-for-all. Instead of measuring the completion towards a predefined goal based on anticipated customer reactions, you should measure the team’s capability to resolve issues and deliver features. The more efficient your team is at delivering the outcome, the more likely you will be to solve your actual problems.

An added benefit is less micromanagement and chasing new senior management impulses, but focusing on long-term improvement of the same metrics.

Your focus should be on measuring and improving your CycleTime, Flow/Work in Progress, and TimeToFix. These metrics can be scientifically determined and measured, and progress can be shown – when you combine them with your business metrics, you have a sound governance model for your teams.

How ProductDock can assist: We can support you with experienced Agile coaches who will track and improve the metrics mentioned above together with your team. Our Agile coaches and consultants will also assist you with reducing your lead times, allowing you to collaborate interactively with your customers and end-users, ideate new solutions, and quickly validate them. The repeated delivery of valuable outcomes will earn you much more trust than good explanations of why the outcome is not as hoped.

We cannot afford to rebuild technical components over and over again – don’t we need to do it right the first time?

Many product development initiatives fall short of financial, time, and technical goals. Undoubtedly, bad planning, strict procedures, and leadership all contribute. Another factor is managers’ expectations that their employees must “get it right the first time.” Requiring first-pass success steers teams toward the safest solutions, even if consumers don’t think they’re any better. Worse, teams lack the motivation to find creative answers to client issues.

Tolerance for “getting it wrong the first time” may be a good approach if individuals iterate fast and learn from their mistakes. Low code platforms, public cloud providers, fast prototyping methods, and a rich set of easy-to-integrate SaaS solutions have made this much simpler and cheaper.

Experimenting with a variety of concepts is vital to creativity. In a fast-paced environment, many fresh ideas will fail. Early failures are helpful because they enable teams to swiftly remove bad ideas and concentrate on more promising ones. These results may be beneficial if they occur early in the process when minimal resources have been committed, designs are still flexible, and alternatives can be attempted.

Waste, in the old and static world, was code that was not reused. An entire industry thrived on telling enterprises that everything needs to be reused, with a suite of EAI, SOA, ESB solutions, and other three-letter acronyms. Waste in the new world is code that never needed to be written, as the anticipated problem never occurred. Waste is code already going into a custom-built solution as a consumable SaaS offering. Waste is a missed opportunity to make the customer happy.

How ProductDock can assist: The desire to build something right the first time often comes from the misunderstanding that the problem is defined, understood, and “solved in theory.” Hence the solution just needs to be built efficiently. During our initial discovery, we will develop an understanding with you in terms of which technical capabilities your problem could benefit from, and we will scout the first SaaS candidates for you. We will review this capability map continuously with you and delay investments and configurations to the latest possible moment to allow you to experiment as freely, i.e., as cheaply as possible.

If I enable the team entirely, I will be utterly dependent on the team in the future. How can I prevent being dependent on an external vendor?

This is true.

How ProductDock can assist: We offer you the option of handing over teams into your organization in a model we call Company as a Service. This model allows you to build and experiment on the product without upfront investments or risks. If the product succeeds, we will provide you the option of taking over the team into your own nearshore development center.  

Conclusion

Not everything will go smoothly when adopting a new product-based approach to software delivery. But it isn’t a failure if things don’t follow the initial plan. Utilizing an agile, iterative approach is key to ensuring your team understands the problems you’re trying to solve and craft the best possible solutions. Remember that failing fast and often can be an effective strategy for quickly identifying and resolving issues. As long as you’re open with your customers about what you’re working on, any delays or setbacks should be easy for everyone to understand.

We hope that this FAQ has been helpful to you! We’re always happy to help. If you have any questions or concerns, please reach out to us at contact@productdock.com.