Managing any large project is complex, full of risks—and faced with a natural reluctance toward team-client collaboration. As a project manager, you cannot mitigate everything: you need to put the expertise of your team front-and-center to navigate each challenge.
This requires a team-focused and agile mindset where you place your focus on impromptu coaching and relationship building between your team and client. If orchestrated well, your client relationship will be rewarding, your team will be celebrated and your project will enjoy the best outcomes.
But, as a PM, how do you pull off a client-facing development team?
I’ll show you how we did it, and why.
- Type of client company: Staffing
- Type of project: App development
- Cost range: 1 to 1.5 million
- Timeline: 2.5 years
- Team size: 4-8 at a time
- Methodology: Scrum
Define, develop, launch and support
a new multi-platform staffing app
Successfully execute a significant development effort not tied to deliverables
Why We Opted For Developer-Led Collaboration
Just a few years ago, my team was much smaller than it is today. We wanted to grow, which meant we needed to find larger, more complex projects.
For us, we knew this would bring a new set of challenges, with the most important being changing the way our developers collaborate with our clients. We understood there was value in connecting our developers directly with our clients, given their expertise. Yet we also wanted to be able to stay true to ourselves and our clients, producing quality work.
An opportunity came knocking from a startup in the staffing industry.
Unforeseen to us at the time, it would allow us to experiment with this new approach to developer-led client collaboration.
We started with an on-site, 3-day consulting session to help the staffing startup refine their product vision and market.
They loved working with our team and asked us to put together a contract for developing the initial release of their platform. It included a web app, marketing site, iOS app, and Android app.
Our client wanted to move fast and was ready to build.
Great, right? Not so much.
The problem was, our client was ready—and we weren’t.
First off, our team only had 3 days of exposure to understand the product.
With a scope this large, we knew we couldn’t confidently deliver a contract that detailed every feature and edge case, as it required months of multi-platform development.
Not only that, it wouldn’t be fair to our client or team to engage this way.
Our client was building a new product, which would require significant learning and trust from our developers, not to mention frequent testing and gathering of user feedback to ensure success.
So, we created an agile contract.
Due to external timeline pressures to get to market, we couldn’t pursue our traditional discovery route at the time. Our team needed to come up with a solution that empowered our developers to create the best solutions. The scale and timeline couldn’t afford detailed scope negotiations and addendums.
After much internal debate, we created our flavor of an agile contract, or what we now call, “Duration & Price.”
This contract was informed by a list of user stories our product strategist created during the 3-day consulting session. Most critically, it set up a collaborative framework for our developers to lead our client partner.
The focus of the contract was a product team that we felt could deliver on the challenge.
Our team included a cross-functional web developer, backend developer, and a mobile developer. We also included a product designer, product strategist, and myself as a project manager. Each team member was set to various capacity allocations that made sense for the project, generally at half or full-time capacity.
The contract wasn’t hourly either, it was fixed-duration, and committed our team to complete specific project goals, without focusing on specific features.
We felt this approach put our best foot forward, provided autonomy for our developers, and made the most sense for the client team’s priorities.
Here’s What Happened With Our Client-Facing Development Team
After the contract was approved, we began work.
Coming into this without detailed technical or product discovery meant, as the project manager, I needed to rely on the team to collaboratively define the approach with the client. We had dabbled with Scrum before, but this became our first true scrum project as an agency, daily stand-ups and all.
We relied on our ability to break down user stories.
Starting development was a large undertaking that involved a lot of upfront risk management with our client. Since our contract was not based on a fixed set of deliverables, we had to show that our work, team, and process could be trusted within our first few sprints.
To do this, we referred to our initial, high-level list of user stories. We reviewed them as a team and identified where they could be further broken down and refined.
During this user story mapping process, we also determined technical discovery tasks for setting up our environments and identifying how we were going to build out the API data model. In turn, these would inform the estimation of user stories we were unable to estimate upfront.
We created design tasks separately and we managed their dependencies on our user stories for development. Throughout the development of this platform, the design would work ahead of development.
We saw that transparent communication with the client during the first few sprints would be key.
We consistently walked through the process of what we were doing and illustrated that we would begin to define a reliable velocity metric within a few sprints’ time. This would then allow us to collaborate together on a refined release plan as initial development stabilized.
Scrum gave us a framework to effectively and transparently collaborate with the client team.
We started our sprints with “Wednesday Kickoffs” with our team and client.
As the project manager, I facilitated these meetings. However, I intentionally did not choose the outcomes of these meetings. Rather, the client would speak to priorities, and the development team would directly consult with the client from their technical or design expertise.
The client would suggest that a loosely defined feature be prioritized for development in the following sprint. I would then ask questions of the developers in the room for the feasibility of it, like:
- What do you think?
- Is this possible?
- Do you think working on this would affect our current plan?
- Are there are development libraries or other efficiencies we can explore?
Asking these high-level discovery questions often jump-started a dialog between the developers and the client.
As a result, the client would lean into the expertise of the developers and we would quickly come to a consensus for a direction to pursue. Our developers served as expert guides and technical consultants during these meetings to help optimize outcomes for the client.
We prepared for “Wednesday Kickoffs” with a smaller client meeting.
Prior to the Wednesday Kickoffs, our product strategist and I would consult with the client in what we called a Bi-Weekly Product Backlog Review meeting.
The client would typically come in with a set of desired priorities for each sprint, and we framed the discussion around the context of our team velocity and the client’s market learnings.
See below an example of what we covered in our Bi-Weekly Product Backlog Review (with PM, product strategist, and client in attendance), versus what we’d cover in the larger Wednesday Kickoff meetings (with the development team added to the mix).
Together in this Bi-Weekly Reviews, we would refine the backlog priorities. This helped set up our full-team and client collaborations to run effectively during Wednesday Kickoffs.
We took advantage of a few useful tools…
Managing a complex set of multi-platform apps required the use of collaborative tools.
We used Asana as our project management tool. This allowed us to manage each app’s development individually. Asana is really great at transparent communication via its commenting system, which allowed cross-functional team members and the client team to communicate with each other directly.
We later employed the use of Screenful alongside Asana to have transparent and automated velocity reporting. This was available to both our team and the client.
Alongside Asana, we used a handful of supportive tools, all of which the client and team had direct access to:
- We had our own Slack channels for asynchronous discussions
- We used Zoom for recurring meetings and impromptu collaboration sessions
- We used GitHub to manage our code repositories and provide transparency for the work being done.
…but that still didn’t solve our biggest challenges.
We faced significant challenges as a team but were able to navigate them with Scrum as a framework and our contract as a foundation.
When it came to our mobile apps, my team and client had to rely heavily on the guidance of one of our mobile developers.
For example, developing and managing separate iOS and Android apps was challenging.
Due to the platform differences, it was easy for the two apps to fall out of step.
Fast-forward to the end of the year, our client and team were discussing adding major new functionality to the mobile apps. This would be incredibly important for the future of the product. However, due to the way the mobile apps were built, our development team highlighted that this process would take a significant amount of time.
One of our mobile developers began to experiment with a new development language, React Native. It promised to empower developers to build and deploy native iOS and Android apps with one codebase.
Our developer rebuilt the initial view of the mobile app in React Native and shared it around the team as a proof-of-concept.
The value was clear:
At this pivotal moment in the platform’s development, we could continue to build at a slow pace, or we could rebuild the mobile apps from the ground up, with the new features in mind. Our client could have their cake—and eat it, too.
Rather than take this to the client myself, I worked with the developer to flesh out some high-level aspects of this proposed mobile app solution. I then facilitated a meeting between the developer and the client to propose this pivot.
In the end, the client agreed with the developer and we moved to pivot the development of the mobile app.
This was one of many examples of the value in putting our development team directly in front of our clients.
Our team believes that client trust is essential.
Knowledge and innovation should not be hidden or filtered through a project management role, as it may lead to lesser outcomes for the projects overall.
Not everyone on a development team gets excited about collaborating on a daily basis with a client.
Even though we found this client-facing approach valuable, there were initial challenges to overcome in this approach.
By offering a trusted ear and a candid voice to my team, I was able to help guide daily interactions with our client.
Behind the scenes, I would help coach our development team on how to present solutions, challenges and more, directly to the client. This wasn’t just improving project communication, it was helping grow each team member as true leaders in their own domain. With practice, this was needed less from me.
Eventually, the development team members all individually built incredible, personal relationships with the client.
This mindset continued to take shape throughout our relationship with the client, over its 50+ 2-week sprints.
By the time we handed off the project to the client development team we helped hire, we had built 5 products for this platform, including an iOS app, Android app, web app, marketing site, and an admin app.
Here Are The Results Of Our Developer-Led Collaboration
As we handed off the project to the new client team (which mirrored our team size by the end), we could confidently say we achieved our goal.
Given the long-term nature of the relationship, we measured success by the continued contract renewals. These renewals were supported by growing success on the client’s side of the business.
As with any project, our relationship was not without challenges.
We had many tough conversations, which were approached through a partnership lens. Our two teams looked for solutions together, not separately. This collaboration made development natural over time.
There was no direct accountability to our team in the traditional sense, either. Our team was responsible for continuing to work in the best interests of the product, but we didn’t have specific features to deliver contractually. Using Scrum helped with this approach, as it provided a recurring sprint framework to collaboratively set accountability with the client.
When significant issues came up, we used key tools from Scrum to help guide our team and client through them.
For example, when a release was off track, we would refine the release backlog directly with the client. This helped keep our development team moving forward at a healthy pace, while also successfully guiding release management.
If there was a significant blocker and the client could assist, we would resolve it together with the development team. Putting the development team front-and-center helped us find the best solutions for moving forward.
Transparency was a key value to ensure nothing was hidden.
Throughout the project, we learned a lot.
Notably, results are authentic and achieved faster when your team is helping to define the future directly with the client.
With this, project management isn’t a bottleneck: there’s no contractual scope to manage, so the project manager can focus on ensuring the team is empowered to create the best solutions.
A Summary Of Lessons Learned
What went right?
- Facilitating and guiding your project team to collaborate directly with your clients is more valuable than “managing” your team. They’re the experts in development, not you.
- Using an agile contract empowers both your team and client to focus on building great products through a partnership-driven approach.
What went wrong?
- For a project of this size, tangible delays and pivots were experienced semi-regularly. However, the partnership-driven relationship empowered the team to find, surface, and execute solutions to get back on track.
- Some team members hesitated initially at direct client collaboration; however, this was overcome through impromptu coaching and relationship building.
What would I do differently next time?
- Spend more time identifying blockers and risks early with the team. As described above, this leads to the team promoting valuable recommendations to the client that lead to greater outcomes.
What Do You Think?
Have you experimented with developer-led collaboration or a client-facing team?
What worked for you, and what do you recommend to other project teams who are trying out this approach?
Please share in the comments below or weigh in on the discussion in The DPM Forum.