Product Design is not Product Management

Two years ago, I wrote about what it means to work on a product rather than on a technology.

Well after those two years, I’m even more adamant about this. Actually, I’m pushing it further: designing a beautiful product, no matter how much it actually helps to solve a user problem, is just not enough for your business to be successful.

What could go wrong, while you have the best product in the world? Well, basically, everything.

Your Sales team don’t know what they are selling.

Do your sales even have a clue of what you’re selling? No? You can’t really blame them for that.

In a B2C business, it’s rather easy to eat your own dog food. When you’re building that next great localization-based service, anyone in the company can go out and try it.

In a B2B business, that’s something else. You’re solving an issue for a specific craft, and not necessarily for a sales-related craft. Then, how can your sales know about the day-to-day challenges of the buyer? Have them be supported by pre-sales, who have an expertise in that craft? Well, that’s an idea. It works in some situations. Probably in larger organizations. If you’re a start-up, that’s the Product Management’s job.

Being a Product Manager means that you know your product inside out: you’re contributing to its design, to emptying its backlog by resolving issues for the craft it supports. You know when features/fixes are released, and when others will be. You’re constantly chatting and getting feedback from the users.

There is no one better at selling the product than the person who has such an overview. Don’t get me wrong: you need sales people. Chasing, closing, all of the sales process is a full-time job which requires a lot of expertise. But they need help for the rest.

Your Marketing team can’t plan.

Besides the fact that your marketing team may face the same kind of issue than what we mentioned for your sales team above, they have one more struggle. How can they ever plan some communication where there’s no clear delivery date for features?

“Hey guys, we have a very exciting event coming up! On February 10th, we’re at WhateverAmazingConference. Do you think we’ll be ready to announce the AmazingFeatureYoureWorkingOn?”

Have you ever delivered a feature on time? Do you actually set delivery milestones? In our software world, this is sort of an utopia. I think it happened to me… Twice… No, maybe once… OK well, it happened because we went for refining the MVP. You know what? Scratch this paragraph’s title. I should have named it: you can’t plan product delivery dates.

The trick is actually to stop believing you’ll be able to market something that isn’t ready. Get things done first, then communicate about it. If your marketing team is looking for the wow effect… well, it’s not because you released to prod that people know about it! Even better, you’ll have time to tell a few users, they’ll help you fix the last bugs/issues before you tell the world. Here, a Product Manager supports in 1. managing expectations 2. feeding the marketing team with the essence of the solution.

Users are stupid, customers are lazy.

People don’t read docs. They don’t watch videos. No matter how good your documentation is, how great your UX is, how much money the customer invested in your product: they don’t know what your product is and how to use it!

How to set it up, and how to use it is obvious to you? Well, I’ve got a secret for you: you built it! According to your own mindset by the way. Yes, even if you know exactly what is the user’s problem, there’s always several good (or less good) solutions. You picked one that makes sense to you and your team. The longer you work on a product, the more biased you are. Things become obvious: why would that user not understand that?

Salesforce almost invented the customer success management concept. Why? Because they were very well aware about this. Have you tried implementing Salesforce in your company? It’s a brilliant tool. You can do everything with it! I personally have set up most of the tools we use in our company. When I had to tackle Salesforce, I’m happy an external expert was there to help me. I would have totally messed it up otherwise.

Offering a solution to a problem, rather than purely removing the problem, always means that people will need to learn how to use that solution. And as well all have far too many things to do, taking the initiative to go learn something new is an effort that we rarely can afford. Especially when we were used to another solution, or to simply discard the problem.

Accounting? What’s that?

You’re making money. Congratulations.

Is that money getting right to your personal bank account in the form of your salary? Not really.

Are accountants weird people stored in a dark room at the end of the corridor, or preferably in the basement, who still use calculators while they have desktops? Not really.

Cash flow management, taxes, ledgers… All of those topics need to be understood by the Product Manager. Especially is your SaaS product is sold as self-service. The utilities such as Stripe or Recurly that you’re using to charge your customers do offer a lot of options to support online ledgers integrations and tax reporting. But an accountant’s job is not to know exactly what you sell, that you just released a new module which changed your pricing and business model. And still that impacts his day-to-day job, and his capacity to make sure that all of your tea will get paid at the end of the month. And that there won’t be any risk during a tax audit.

Even holacracy has well-defined roles.

No, you cannot believe that “you’re a team”, and that there no need for titles, roles, responsibilities.

We’re all more and more in management systems where we’re trying to abandon the old command-and-control systems and other kinds of dictatorships. But “being a boss”, therefore doesn’t mean anymore “directing people”. It means supporting them in doing their job.

And that’s impossible without having a few clearly defined leading roles in your organization. They must have a well-defined perimeter.

Why? Because in start-ups you need people with large egos. That’s what is helping you grow, and go fast: passion and ambition. Now if those egos have an overlap in their job, that rarely can end-up well.

In the meantime, not having clear perimeter means that some topics might just not be handled at all. “Yeah well, I though YOU were taking care of it!”. Sounds familiar?

Focus

It’s not because you can XXXX that you should YYYY.

Apply this to development, product design, marketing, sales, partnerships.

Any new thing you start is always impacting all of your team at some point. And even if it’s just you, it means that you’ll be doing this instead of something else. Is that actually going to contribute more to your business than what you were doing previously? Are you willing to abandon something your were doing previous in favor of this?

Conclusion

Product Management is not just about designing a great solution for your users. It is about making sure that your whole organization, no matter what size it is, scrums down in the same direction. It requires to coordinate all efforts, make sure that everybody shares the same vision. It requires that the smallest bug fix can be known about by your sales team, for whom you might just have removed a by thorn in the side. It requires that people who are constantly in contact with users, partners and other external actors can actually feedback on the product and weigh in the roadmap.

That requires lean and clear organizations, lean and clear communication.

Featured image by Riccardo Davico