How to expertly align your developer team, marketing agency & client goals
As a software development partner who frequently teams up with agencies, we’re always interested in how leading companies approach building products to create high value for their clients. Projects which have clear communication strategies that align technical and business teams typically have stellar outcomes. Here’s how our experts keep your agency, our developer teams and end-client goals in alignment to create more effective products and campaigns.
Here at Polcode, business alignment is key to project success, especially when managing remotely distributed teams. When we help agencies build their digital marketing ecosystems, we’re also creating strong processes for product-building. Great team communication is central to this approach.
In the business alignment tips below, you’ll find that clear and precise communication strategies underline each one. When your developer teams, marketing teams and clients have established great communication tactics, it will result in a much happier, more efficient team, and ultimately—your digital marketing products will be far better.
The Discovery Phase
Any partner who designs or develops your digital services should confidently understand the underlying business goals. With every new project, your digital agency and software development partner should kick off with a discovery phase. This is where every stakeholder comes together to try and understand the:
- End-client’s short term and long term goals
- End-client’s expectations (results)
- Types of users, customer segments, or personas involved (more on that below)
- Digital maturity of the users
- Engagement channels (mobile, desktop, social media, chat, SMS, etc.)
Aligning specific KPIs, metrics and goals helps development teams be more effective in their work. Collaboration during discovery is an important foundation in moving forward, creating a clear objective for all stakeholders involved—programmers, coders, and QA testers (not just business managers) makes everything go smoother down the line.
Creating Buyer Personas
Personas are used for signalling common patterns of behavior that result in predictable business outcomes. For example, a common B2B buyer persona is that of a decision-maker who ultimately chooses the products or services to buy for their company.
Planning out personas (or customer segmentation for B2C projects) is usually a great starting point for aligning everyone towards commonly held goals. Establishing end-user personas lets everyone see which features need to be prioritized and added to a project. When we understand what potential customers will need the most, it gives us reliable direction from where to take the first iteration. This includes asking ourselves a few key questions:
- What stage of customers are involved? For example, building services for early adopters, premium subscribers, returning customers, organic traffic or cold leads can greatly shape how product development tasks will be prioritized.
- How do we solve user pain points? From a development perspective, it’s always better to build a solution that solves pain points, rather than focusing on a specific audience or target demographic. From the start, we want to answer one clear objective: how do we solve user pain points better than the existing experience or competitor products?
- What are their buying decisions? If the aim is to convert buyers, we’ll take a solution-specific approach to identify why customers convert. We look at behaviors—when, how and why they make their buying decisions. Any data-driven insights about pre-existing customers will help this stage along. If there aren’t any data insights yet, this is something to keep in mind as a business goal of the project.
By keeping everyone on the same page about how the solution helps users, the end-product is much more likely to meet their expectations. If personas aren’t well identified yet, then it’s also our job to find out more and collaborate with your digital agency to pin down specific use-cases for each persona.
The Minimum Viable Product (MVP)
After the discovery and personas phases, it’s important for us to be careful about any assumptions made. After all, at this stage we’re just “thinking” about the product, business and potential marketing outcomes. To gain real-world assurance, we look towards the first project delivery as a bare-bones MVP, which can easily be tested and validate (or invalidate) our early assumptions.
We use the latest prototyping tools to achieve a lightning-fast delivery of MVPs, sometimes in as little as a week. During this time, every person within the project, including test users, can interact with the prototype and provide feedback. We then conduct a review sessions, where feedback is discussed and directly looped into the next step, where we plan out validation tactics:
- Sign up, onboarding or first-interaction. What are the first goals for the first stages of interaction with the brand? What specific actions do we want users to take? These help guide the project requirements early on, and give us an idea of what technologies will best support these actions.
- Mapping the customer journey. Putting ourselves in the user’s shoes helps us understand exactly how the product, website, app, or feature is experienced. This influences how we’ll go about building the system to meet user’s needs, rather than assuming what they
- Competitor Analysis. Knowing how your direct competitors work gives us a baseline for understanding the project’s position in the market. We don’t want to create the exact same product on the market—we want to make something that works even better, that goes above and beyond serving your target user groups.
Agile Development Processes
When it’s finally time to begin development, communication goes into overdrive, with daily standups under agile methodologies designed to keep every member of the team up to date. Any progress made, changes in scope, bug fixes, or new ideas are discussed in a timely manner, ensuring no details get left behind in the shuffle.
Even today, many businesses unknowingly keep their “technical” teams and “business” management separated through siloing knowledge of their product. This practice is often the culprit for poor alignment between all stakeholders in a project. Living documentation is one of the best ways to keep shared knowledge between these two types of teams.
Living documentation offers a single resource that describes features in both technical, and non-technical ways, creating a common dialogue and knowledgebase for everyone involved.
Every developer knows that great documentation is the cornerstone of development, but extending this concept to non-technical teams can have a lasting impact on alignment. Our living documentation practices vary from project to project, but it usually involves:
- Continuous Updates. With each successive update or release, a living document provides a single terminal for anyone (technical, and non-technical folks) to openly learn, collaborate, edit and update internal documentation of the project.
- Automated Test Reporting. Documentation should describe how a feature or application works and the business implications behind it. But it is known as “living”, because each automated test generates a new report, every time the application is updated. This way, automation takes care of the heavy lifting, and everyone can stay on the same page.
- Accessible project management summaries – Whenever a new feature is implemented, a bug fixed, or progress is made on the project, any person involved in the project should be able to look up exactly what took place. This includes the reasoning behind the change, and which people were involved in making them. This way, any questions that arise down the line can be answered simply by reaching out to the developer.
Communication & Collaboration Tooling
In order to implement the practices above, remote teams require the appropriate tools to maintain collaboration and communication in ways that keep people on the same page. Our developers will always gladly use our client’s preferred collaboration tools. However, in cases where there are none, we provide them along with guidance in how to use them. These tools can include any number of the following platforms:
- Group chat messengers like Slack that allow us to quickly and easily integrate communication layers, and even streamline other processes into the chat itself (via chatbots).
- A good project management platform is the bread and butter of modern software development. Everything from project backlogs, features in development, task lists, documentation and much more should be stored in one easy-to-use place.
- Developer hourly logging is something special that Polcode provides, so that our clients can see exactly what was done, and what they’re paying for.
- Collaborative prototyping tools are often used during the MVP stages to get all stakeholders involved in how the app or feature will work (at least approximately).
Achieving Universal Alignment
Okay, it’s not realistic to perfectly align everyone, all the time, for every project. What matters in achieving business alignment with software development is that good communication is put front and center. Recurring meetings aren’t always enough to get sales, development, business, marketing and testers on the same page. Instead, practicing team alignment at every stage of the process ensures that everyone goes through the same journey, instead of experiencing an end-result. By moving towards the same goals, you can reverse-engineer ideal business outcomes without leaving anyone behind.