I’m fortunate to have been involved in the Software as a Service (SaaS) field in a number of different ways. I’ve been a developer, an owner, a sales guy and a team manager. My team are currently involved in the development of our own SaaS product (a CRM system). Additionally, we’ve worked with our own clients on a consultancy basis to help them build up their own SaaS products for market.
During many of the projects that I’ve had sight of, there tends to be a pattern that, if left unchecked, could lead to the destruction of the entire product. Even so, it’s a risk that doesn’t rear its head until the first Minimum Viable Product (MVP) or Beta product is launched. Let me share it with you in the hope you’ll avoid repeating some of the mistakes of others.
I’ve often pondered why this problem is so prevalent and not always even recognised as a problem. It could be because the product development team are solely focused on the problems associated with software development, or because they think the worst is over. Or it could be the eagerness to go-to-market is too strong. To be honest, I’m not quite sure.
What I do know is that the problem starts — somewhat paradoxically — with the whiff of success.
Just whose product is this?
If you’re following the Agile development method, or at least some kind of product feedback protocol, then you’ll be delighted to receive enquiries from your first users. You’ll be smiling and happy knowing you’ve finally got some traction.
Yep, those are often the first symptoms.
Here’s a typical email that you’ll get:
Dear Ace Product,
We’re a 30 user team that are looking to move away from our current supplier and after looking around your Ace Product looks a good fit for us.
In order for us to move forward it would be good if the product could {insert requirement}, {insert another requirement} and {yet another requirement}.
We’d be looking to make a decision on this in the next few weeks.
Yours,
Very Sincere Client
Wow, 30 users,eh? Great start … and those requirements weren’t quite on the roadmap and it will stop you doing feature B and C but this looks like it’s in the bag. Let’s have a meeting with the development team …
For readers that don’t already see the issue, you as the product owner have now ceded the development roadmap to a … well, I was going to say “client” but you’ve actually ceded it to a non-qualified prospect.
Of course you might be in luck and that enquiry fits exactly on your roadmap. Great. Just reply and say that it will be ready soon (don’t give a date!) and that you’ll be in touch. That’s right, the non-qualified prospect doesn’t get the right to dictate your product development pace either.
Moreover, keep at the very top of the pile that you are the Product Owner.
There’s Good feedback, and Bad feedback
The MVP/Agile/Feedback cycle that you may be following dictates that you should always encourage feedback. As the Product Owner, however, you need to make sure that you interpret that feedback correctly.
Firstly, try to avoid making the mistake of road-mapping the features that the client has asked for. Instead, look to solve the problem that the feedback outlines. I would personally go even further and say that you should ignore all feedback that is a list of feature requests, but that’s up to you.
Secondly, always take your processed suggestion and think about how that will affect all of your other, existing users.
Thirdly, keep in mind your value proposition. Does this new feature that you are building satisfy the core objective of your product? If not, you might want to justify your position by suggesting a solution outside of your product. This suggestion might address the way the client works or the tools that they are using. Either way, be strong that it’s not always your problem to solve within the application.
We’ll pay you …
Nothing will test your resolve of product ownership more than when a prospect or existing user comes along and offers to pay you to develop a feature that they need.Money in the bank and a happy client sounds so much like a no-brainer that it’s difficult to say no to that one.
But you should say no, and you must.
Product owners that hand over the pace of development, the priority of development (roadmap) and the scope of the product are not … well, they’re not product owners.
If you genuinely thought that the requested feature was a good one — and it will benefit your users and is a problem for your application (see above) — then you should consider doing it anyway. Taking money simply cedes control of the detail.
We’ll pay you … (revisited)
In a variation of the client payment model, you might be given the opportunity to make a bespoke version of your product for customer X. They’ve said they’ll pay you for it but will need some customisation to make it work for them.
While I’ll stop short of an out-and-out No to this one, here are some notes on why you should think long and hard before agreeing to something like this:
- It’s likely customer X’s core code might deviate from the core code of your product as part of the changes you make for them. From a technical perspective, what is the plan to keep the core code well maintained?
- In a similar vein, how will any new features in the core product be reflected back to customer X’s platform. Or will they not be applied?
- How have you valued the price that you’re charging for your platform? Does it truly represent the value that it is worth?
- How are you structuring the legal agreement between you both? What if you sell your product, what if they stop paying you? Do they own the stuff they’ve paid for? Etc, etc. You get the idea.
That’s not exhaustive at all but should be enough to make you think twice. Also, if the client is a good match for your product wouldn’t want to keep their ideas within the core application?
And, in case it needs point out, from the moment they agree a deal with you they’re no longer a SaaS client of yours, so any attention you give to them may well be at the cost of servicing your core user base.
You can see why I suggest caution, right?
Time to say No
Some people take saying No to clients in their stride and other, like me, find it a bit of a challenge. My own background is in finding solutions for clients, and more generally in sales, so it doesn’t come naturally. Of course that doesn’t mean that saying no shouldn’t be done.
Where possible, try to explain the solution that you think will work for them, outside of the product. This might include emphasing what your product aims to do and why that requested bit of functionality is not an ideal fit.
I’m not too keen on them but there are also ways which involve kicking the request into the long grass. Saying you’ve added it to your roadmap when you haven’t might solve the initial problem but it’s not good practice. The same goes for other untruths that don’t reflect your intent.
Moreover, try to help where you can. Point out alternative products that offer that feature. After all, there’s a reason you’re not implementing it so you shouldn’t be shy in signposting to a competitor, right? You might even gain a few Brownie points along the way.
Takeaways
There’s much more depth to this and being a Product Owner involves making tough decisions like this more often than you’d think. But one of the outcomes from those decisions must always be to say No.
- Remember it is your Product, not the user or the prospect’s;
- If you say No, try to do it positively, but say it clearly;
- Being paid for custom development work can seem nice but it’s a distraction;
- Maintain empathy with your existing users;
- Never cede control to anything around your roadmap including timing, path and features.
David McLeary is a director of Cambridge Software, a software development and consultancy house that develops products for clients as well as having their own suite of internally developed SaaS products, including RealtimeCRM.