To create an engaging digital customer experience requires three things: product management know-how, design savvy and engineering expertise. For enterprises, particularly financial institutions, to achieve this in-house requires significant time, money and resources at a time when hiring and retaining top designers, product managers and engineers is near impossible with the market drowning in demand and lean on supply.
To address this challenge, many CMOs, CIOs, and CPOs frequently engage with outside agencies (design, innovation and advertising) to fill this gap. However, how do they truly know that the partner they are selecting meets all three of the above criteria? Many digital agencies will say that they can develop digital products, but in reality may only execute part of the strategy, create a stellar design, and then hand off the development to a partner.
Following are the top four signs that the agency you are either considering or have selected may not be best suited for helping you with digital software products.
1. The agency starts with functional requirements
Product strategy should not start with requirements, which is how agencies typically operate as shown in the following image.
A digital product may start as a project, but it has its own lifecycle, roadmap, and go-to-market strategy that should be created prior to functional requirements. The fundamental activities that your product team should embark on are as follows:
Creation of a product charter that helps the team align around objectives and establish the venture’s ROI
User research workshops that initiate the conversation with the end customer, internal or external, to make sure that the product is designed for the right reasons
Heuristic analysis, lean canvas, and other tools to further extend the strategy definition of the product
Lean requirements workshops that allow the cross-functional team to identify the feature landscape of the product and build alignment across the product team and SMEs
Persona creation to establish the audience and user roles of the product
Roadmap planning and prioritization exercises to shape the release plan of the product into MVPs, MMPs, and dictate the investment theme
Once the strategy is defined and high-level product requirements are established, the cross-functional team should perform a just-in-time requirement definition as they iterate over the product scope using Dual-Track Scrum. Requirements will be captured as acceptance criteria within user stories of the product.
To summarize, requirements for the product should be defined throughout delivery, not prior to the project kicking off.
2. They start with design
Agencies will often start the project by designing style tiles, sketching out wireframes and even producing high fidelity mockups of the product to make sure that all client stakeholders are aligned and buying into the vision. All pages and interactions are catalogued into a large artifact file or prototype site with tens, if not hundreds, of pages. This document serves as a guide that gets handed over to the development team to implement the product. Seems like nothing can possibly go wrong. Except that it does.
First and foremost, even if engineers use agile to build the product, the process used to this moment is inherently waterfall. All requirements collected first, then design is produced, then development is completed. At no point in time is the product at least partially validated, technical spikes performed, or user testing sessions carried out with working software. Furthermore, stakeholders tend to get fiercely emotional about the design decisions that have been made, preventing the product from beneficial pivots. The design decisions are not vetted with the engineering team, thus leading to scope and budget getting blown out of proportion by the time the vision is implemented.
What’s the alternative? The cross-functional product team should work together through the product backlog, designing and implementing small modules of functionality that can be demonstrated to stakeholders as well as tested in real world scenarios. This guarantees that designers don’t over-invest and that engineers perform the necessary technical spikes to guarantee the viability of the proposed design.
An iterative approach also guarantees that the stakeholders don’t get bogged down by minute visual details while they should be focusing on the overall product roadmap and value to customer.
3. They bring in their development partner; they are not the developer
Agencies will often embrace strategy, innovation and design services yet leave development, quality assurance, and DevOps to partner companies. While managing all of those disciplines under a single roof is certainly a handful, a practice-segregated approach will cause more damage than good.
The benefits of a cross-functional team are as follows:
Better product design decisions can be made when technical and design team members ideate and solution together
Nothing is lost in translation as developers are participating in review and acceptance of design deliverables
Development deliverables are reviewed by design and design QA is performed on the interfaces, resulting in a higher fidelity product
Quality Assurance team understands the acceptance criteria much better as they are participating in design decisions and understand the behavioral models of the users
Developers can create proof-of-concepts and spike certain design decisions ahead of time, without risking major investment. Additionally, design decisions do not result in dead-end features because they are reviewed by developers
Ultimately, a team that covers the three core disciplines of Design, Product Management, and Software Development will be leaner, faster and deliver a better product.
4. There is no post-launch plan
After requirements are collected, the user interface designed and the software developed by a partner company, the project is finally ready to wrap up. The agency moves its team members to other initiatives, perhaps leaving behind just the Project Manager. The product has, to date, move from hand to hand across multiple teams, companies and even stakeholders. The original vision has been diluted, the budget expanded and ownership decreased.
We’re forgetting one of the most important elements of product design, however. The first version is never on target or completely successful. The ability to react to failure and as a result improve the product is in the DNA of an innovative strategy, but most of the team has since moved on. The first release, the MVP, hits the market with lukewarm results, but the budget to date has been exhausted. There is little room to pivot or leverage real customer testing to improve the product and dial in the value proposition. Distributed ownership results in design, engineering, and project management all blaming each other for misinterpreting requirements.
In an ideal scenario, the cross-functional team is focusing on bare minimum features to get working software out the door and into customer hands. Within four to six months the MVP is live and real-world customer data and tests are collected to understand how the vision aligns with actual usage patterns and value created for the customer. User Testing sessions are used to refine the product backlog beyond the MVP, potentially pivoting the MVP2 to address newly discovered value. Some rework is expected, but the team has not exhaust the budget to date, so the rework is minimal, expected and tolerated within the investment theme. A live product validates the charter and demonstrates value to investors, opening a conversation for further investment.
Most important, the whole team—designers, product managers and engineers—see the product go live. Everyone is involved from day one to go-live, reaping the satisfaction of taking a product to market, as well as riding the wave of success to the next version of the product.
Summary
Many design, innovation, or advertising agencies pick a subset of disciplines to focus in, which creates significant risk in leveraging these services. Product quality suffers as a result. In our experience, cross-functional teams that include Product Management, Design and Software Development generate more value for the money in a shorter period of time along with the a better quality product over the long-term.