More than a year ago I wrote a post about why software projects fail, and it’s still popular because so many projects go wrong. We’re always working to minimize risk for clients, and as part of that goal, we often focus on something we’ve learned over 100+ successful projects. Here it is: One of the best metrics for success is how well a client engages with our team. It’s something we’ve known for years, but what does it really mean?
I think over time we’ve been refining our expectations. When Gaslight started back in 2009, we were happy if a client showed up at daily status meeting three or four times a week. We’ve also wanted our clients to test and accept software features as we build them from the beginning. But more and more, we want our clients involved in the day-to-day design of their products. We’re asking them to take on the role of product manager.
What’s a product manager?
Being a product manager is taking on the responsibility of figuring out how we get from where we are now to the final grand vision for the app. What steps should we take between here and there? A product manager doesn’t need to be a developer or designer or even particularly technical. The most important thing is being involved in the day-to-day decisions about how the product should work.
Being an effective product manager requires a tough balance between being strategic and tactical. You’re likely doing research with your organization on how the software supports larger business goals. But you’re also helping the team figure out tactical details, such as how pricing products works at your company or what happens on a factory floor.
Right now I’m working on an app where the product manager works half days in our office next to the designers and developers. This helps our process move faster because she’s available to answer questions that come up as we’re building. She recently helped us clarify her company’s payment terms (net 30 or due on order?) and figure out who at her company should be able to edit a customer’s payment terms in the app. If she wasn’t here, this question might have led to a delay of half a day or more.
Prioritization is another critical piece of product management. What’s most valuable to your business? There is always more to do than time or money will allow. So it’s crucial to understand the limit and scope of what’s currently built at a high level and choose what to do next.
Do you need your customers to be able to create accounts on your website? Or is it OK if only your internal staff can do that for the first version? It’s about weighing needs and wants against time, budget and ROI. Product managers work with the team to cut scope while still creating software that’s valuable for their company. It’s about understanding what outcomes we want to achieve and making some tough choices.
Why can’t you do it for me?
Many of our clients are new to software development. They might envision attending a kick-off meeting to impart a grand vision then taking part in status meetings. But this approach doesn’t lead to great software. We have the technical and design know-how to build great products. But we don’t know what parts of an app are most valuable to a client’s business. Or what order we should build things in to deliver value as quickly as possible.
These are decisions where we can provide guidance and advice, but for a truly successful project, we need to build a strong, highly engaged partnership with our clients. We’ll help our clients understand the technical nuances and the steps of agile development, and we look to them to manage the day-to-day decisions as we develop the project. Plan out a feature or two ahead of what we’re building now. Dedicate half their week or more to the project. Build a strong relationship with the design and development team.
We can do the actual building and project management, but we need clients to manage a product’s direction and that requires a lot more than just showing up for a daily status meeting.
Do I need to work in your office?
We work with clients all over the country, but for those who are local, there’s a good argument for being on-site. Even if we’re not directly engaged in conversation with clients about a particular problem or question, it’s beneficial for them to hear the back and forth conversations between the designers and developers on their project. It exposes clients to our culture and process and gives them a leg up on diving into their role as product manager.
Many clients work here one day a week or half-time. But we’ve had some move into our office and co-locate several staff members for their project’s duration. This allows us to take part in all the business discussions happening among the client’s team. It gives us deeper insight into their process and shortens the feedback loop. We don’t have to wait for the client to have a meeting at their office then bring feedback to us.
Remote clients often schedule more meetings or calls with us. And many fly in part of their team for the first week or two of the project. Or we’ll fly our team to them. Working side-by-side in the same space helps deepen relationships and build a true partnership faster. It’s an extra layer in client engagement that can help us build better software together.