As a consultant for over 20 years, I am very familiar with projects. Projects have a scope. They have a schedule. They have a budget.
When it comes to Sitecore, it is very tempting to use projects to do everything: A project to stand up the platform. A project to build a site. A project to add an integration. A project to add a new set of templates and components. A project to do an upgrade.
Each project is a transaction. Each team is temporary. Subject matter expertise is transient. With “success” defined as being on time and on budget, rarely do we know if the original business case that sponsored the project held true – not to mention the technical debt incurred due to timeline and budgetary pressures.
Instead of thinking of your platform as a series of projects, a better way is to think of it as a “product” that your customers consume when they interact with you digitally across all channels. This approach recognizes that a product is more than a website, more than a CMS, and more than any one tool or touch point.
The product is how you connect to your customers digitally. The product never stops changing. Just like Apple releases a new version of the iPhone every year, your product will continue to add capabilities and better serve your customers, hopefully driving the KPIs that matter for your business.
A Better Way to Work: Product Teams
If your platform is a product, then you need a product team. Unlike a project team, a product team is funded on a rolling basis with periodic reviews working against a roadmap aligned to product/business strategy.
Product teams are cross functional. They are made up of the skills needed to deliver new value over time. This includes development and testing, but can also include visual design, personalization, analytics, SEO, and expertise in other tools as well. The make-up of the team can change over time as well as can the need for some of those skills.
Instead of a Project Manager the team is managed by a Product Owner who prioritizes the backlog and helps clear obstacles for the team. Often a Product Owner is supported by a Product Manager who manages the team day to day, running agile ceremonies and ensuring the team is meeting objectives.
The success of that team is determined by improvement in the metrics related to business outcomes and proven by the Product Owner, who uses data to demonstrate the impact of the work being done.
The team operates in an agile fashion, grooming the prioritized backlog, working in sprints toward frequent releases. Features are truly iterated on, being launched, gathering data, and then being improved in a subsequent release.
Advantages of a Product Development Approach
Taking a product development approach brings several advantages that you wouldn’t see with a traditional project-based approach. These advantages include:
True Agility – Because product teams work in an agile fashion they can respond to feedback and changing business priorities. Feedback can also include real data. Incorporating an AB testing strategy when introducing new features allows teams to see the business impacts of the changes they are making and double down on the things that are driving the most value.
Improved Velocity – new teams often take time to gel and some projects may be too short to actual get to that point. A dedicated product team will get better at estimating and delivering on their estimates as they understand the codebase and each other’s strengths and weaknesses.
Benefits of Domain Expertise – Because team members are focused on an area for a longer period, they become experts in both the code base and the problem domain, offering valuable insights that others may not have without that context.
Better Architecture & Maintainability – Usually a project team builds something and then hands it off to another team to maintain it. They don’t need to live with the tradeoffs and technical debt they helped create. Product teams must maintain what they release and are incentivized to avoid technical debt, as they will be the ones that have to deal with it with every additional release. Teams taking ownership of different parts of the codebase allows for accountable autonomy.
How to Create Product Teams
When it comes to the Sitecore Platform, you can create a single product team to support the business goals end to end. But depending on your organization and competing priorities, it may make sense to have several teams owning different parts of the solution with their own business stakeholders and Product Owners.
The first product team that is usually formed is usually the Core Platform Team. This team focuses on introducing platform capabilities to the business, owning the overall architecture and maintainability of the solution. They typically manage the releases as these may need to be coordinated across multiple teams. This team may also include maintenance developers that work on maintenance issues to avoid distracting product focused teams; however, maintenance is sometimes run as a separate team.
If you are managing multiple sites or brands that have different stakeholders, it may make sense to create product teams that address the needs of each. When collections of sites are managed by different business units, it may make sense to have separate teams for each.
With larger more complex sites, it may make sense to create a team around different functional areas. Common examples could include Search, where thinking through how to optimize how customers find products or doctors drives significant value. Another example could be member self-service where the team’s mantle is to reduce support costs or retain customers.
Ideally, each team is self-sufficient and can iterate on features independently, but this can be challenging if there is not a lot of experience in optimization and analytics across the teams. We have seen that having a dedicated optimization team is a good way to advance past the “crawl” stage of optimization enablement. They can work with other teams to set up and run experiments and get them on track for success.
If most teams are focused on web experiences, it may make sense to set up a separate team that focuses on the entire customer journey. Across the website, email campaigns, call centers and social connections they can work across multiple platforms and technologies to optimize the experience and really target KPIs.
It’s also worth noting that teams should be long lived, but do not need to last forever. It may make sense to spin up a team to cover a set of initiatives, but then wind them down or merge them with other teams when appropriate. The point is to align them to business goals and take an agile approach to delivering value.
How We Help Our Clients
Product teams should not be made up entirely of consultants. The Product Owner should be a leader in the business. Besides that, they need to have the skills to iterate and deliver the value that is expected. We partner with our clients in many ways including:
Independent fully functional teams – We can spin up focused teams aligned to intake or implementation with skills needed to work on a prioritized backlog.
Perficient-led hybrid client team – We can also build out teams that blend Perficient and client resources, with Perficient in leadership positions to drive mentorship and knowledge transfer, allowing for client resources to take more ownership and leadership when they are ready.
Client-led team – We can supplement existing teams with additional expertise or capacity to meet current needs under the direction of existing client leaders.
We also typically like to make our engagements flexible to spin up and down resources and allow us to bring in specialists. If there normally isn’t the need for a full-time content strategist or SEO specialist but a project comes along that requires one, we’ll be able to accommodate that request in true agile fashion.
If you’re interested in exploring ways of working together, we’d love to help. Reach out to me on LinkedIn, Twitter or fill out our contact form.
Leave A Comment