Sometimes an idea will defy articulation until all the dots connects. And sometimes dots just connect when many more articulate people share their ideas. A few enterprise SaaS concepts I’ve been playing around with in my posts over the past few months recently came together:
your primary / target persona works within a larger, cross-functional process (hence you need to identify and activate latent adjacent users)
work happens collaboratively (vs individually), and the team is now the primary persona to build for (which is why you must default to multi player)
enterprise spend is focused on products that boost the efficiency and effectiveness of teams (i.e. productivity is the ultimate ROI)
Of course, there are no new ideas. Peter Drucker essentially spelled this out 50 years ago:
“There are no marketing problems, there are no finance problems, there are no accounting problems, there are only business problems.”
The gist here is an enterprise software solution (i.e. your product) needs to enable a horizontal pod with a job to be done vs a vertical persona that’s a step in the flow. Focus on design, not just designers. Focus on development, not just developers. Focus on research, not just researchers. Focus on sales, not just sellers. There are companies and products popping up around each these jobs to be done, and this article (nominally about why Salesforce bought Slack) walks through several examples.
There is nothing as succinct as a Tweet to drive the point home.
Products are workflows. It’s obvious once you see it. But the challenge (no one said PM-ing was easy) is getting your average enterprise customer to see this point of view. Some specific hurdles I’ve written about before:
enterprises measuring (or even caring about) team-level productivity
team-level productivity actually correlating to business outcomes
team definitions maturing from hierarchy-based to pod-based
Again, there is nothing as succinct as a Tweet to drive the point home.
I’d love to hear from readers who have found success (or just learned from) building for multi player pods in the enterprise - please chime in via comments👇. And if you enjoyed this post, please consider subscribing.
further reading / references
an evergreen post on enterprise loops that talks about the shift from individual to team productivity and how to identify the adjacent users that your product needs
this summary of a Scott Belsky podcast highlights the need to default to multi player and treat the team as the primary persona / atomic unit in a company
Deep Collaboration is an attempt to explain the trend (and coin a term) of collaboration and productivity tools coming together for an enterprise JTBD
Kevin Kwok’s Figma essay explains that “design is larger than just designers”, and you can continue the analogy from there into other enterprise workflows
David Sacks makes that the case that all the metrics you care about in enterprise SaaS (deal size, retention rates, seat expansion) are better with a focus on teams
an interesting plea via The Knowledge Project for business education to focus more on “problems that sloppily span across a bunch of domains”
if you liked the Tweet from Maggie, you might enjoy the Build podcast episode I recorded with her recently (it’s a strategy teardown of a well-known product)
childish drawing / interpretation
Thank you for another insightful post.
Additional thought about, 'an enterprise software solution (i.e. your product) needs to enable a horizontal pod with a job to be done vs a vertical persona that’s a step in the flow'.
This is also true for many incumbents that are undergoing 'digital transformation' (yeah, I don't like this term either). TL;DR, for many of us who are building productivity products, it is easy to forget it is never just about the software; for every software-enabled workflow, there is human operator behind it (unless is full automation). So start with the people and workflow.
I previously joined a fortune 50 company to help them digitize/automate internal sales workflow.
The project was a hand-me-down and had been conceptualized since 5 yr ago but never fully built out.
I took it over and it became fairly early on that the problem was not about building out just the piece of software itself; that was prob the easiest part. It was the workflow or lack thereof: whoever the owner of the project was hadn't taken the time to create/communicate 'what the new workflow would be once there would be an order management portal' and 'what training would be needed for the sales and operation team'. Hence it failed to collaborate/rally support from Sales/Operation senior management to push the project forward.
So my approach was to first map out existing workflow, identify where the friction/pain point was; mostly done by interviews with every team involved in the existing workflow. Then worked with design and eng to sketch out what the ideal workflow and UX/UI components were; how the backend data flew and what different systems and APIs need to connect/create.
We then would show 3 different version of the UI along with workflow description presented to users (internal/external clients); gained feedback and redesign before we started any coding.
The launch was not without hiccup but in every step we were very confident we had the support from users as well as heading the right direction.