grandvoye

I recently wrote https://staysaasy.com/career/2021/10/16/mentorship.html about mentorship

My narrow advice would be to make a list of 20 questions you’d like to ask someone. Then reach out to people on LinkedIn you think could give you good answers and ask them if you could pick their brain for 30 minutes. Then ask those questions and say thank you a lot.

We’ve been front page a handful of times with fairly consistent results. Front page (not first) - 100 to 200 points, 10k day of post, falling to hundreds subsequent days.

The one time we were top post it was 30k visits that day. Thousands the next. Then hundreds the following. Almost 500 points.

It’s a great feeling when it happens. Community comments are super insightful and thought provoking as well.

And McDonalds feeds 1% of the world every day.

I strongly recommend just sitting him or her down and explaining why this is a problem (you've articulated it well here). Either they get more diligent (great) they can't get more diligent (not great) or they refuse to be more diligent (really not great).

I think that there's sometimes a tendency to overthink management topics - there's no need to overthink this one.

IMO the biggest barrier to blogging (and the cause of most blogs dying) is inconvenience, and minimizing that if the biggest advantage of Markdown + Git. If there's any inconvenience at all, it naturally drags on the process of writing, and writing takes enough time and focus that if there's any friction it's too easy to push things off to the next day.

My co-author and I use Markdown and Git as the author suggests, and one of the best things is that between simple CI/CD pipelines and effortless scaling of a static site, we don't need to do any technical work so there's no friction on my lifestyle. We've been writing for almost a year now, 4+ posts a month, and 99% of that "work" has just been writing.

Writing with a partner helps a ton as well.

Hey good q. I work in enterprise SaaS and our team builds a fairly complex product. We have a range of technical and non-technical users within a given account, who use our product in different ways, and we have accounts that range in size from dozens to hundreds of thousands of employees with the differences in terms of usage patterns and needs that you'd expect. We also operate at high scale so our engineers need to know a lot about distributed systems and the integrations that our product has with other vendors/platforms/etc. We aren't unique in any of this from my experience.

(sorry for being somewhat vague but I try to keep this account anonymous!)

It's simply too much for our engineers to spend time deeply understanding every nuance of our business ("how should we make this product tradeoff between the needs of SMBs in Asia vs. the needs of our largest 10 customers across all countries? How will this then impact our pricing strategy?"). But PMs have more context here, because in exchange they don't (for example) know every nuance of how our data pipeline works.

In terms of how we make it work, we 1. try really, really hard to align incentives between Eng/PM so that they win together, 2. make sure that teams work together closely and have time to bond, and 3. write things down in planning docs as much as possible, as that's one of the best ways to reduce conflict and also fully leverage non-overlapping expertise.

"the PM's business expertise has usually been strictly less than the most experienced engineer on the team, leading to a typically never-ending, and eventually abandoned game of catch-up."

That's rough... those don't sound like good PMs to me fwiw.

What I have seen are cases where very senior engineers have a better grasp of the overall product vision than some PMs, due to experience and tenure. But they usually don't have more expertise in all of the business questions simply due to relative lack of time spent in that domain.

***

All of this isn't to say that engineers don't need to know about the business, or that it isn't a huge advantage if they do (it is). Just that there are so many hours in the day and eventually you've gotta get some division of labor.

The challenge I've had with that model is that as a company gets more complex, having someone whose sole job is to focus on the business <> technology interface is invaluable as people start to specialize. It's often more valuable to have engineers with (say) 6/10 expertise in the business and 10/10 expertise in their technology domain, working alongside PMs with 10/10 expertise in the business and 6/10 expertise in the technology. It's simply very hard to be 10/10 in both domains.

I agree that PMs are largely overhead in the early days of a company, provided that you have strong product-minded engineers/designers.

(Also just my 2c from heading a PM department / being a former engineer)

Yup, and it's also an aggressive flywheel:

- You are thought of as a leader - You get to invest in better companies because they know/want you - The better companies outperform, because they were better - You are increasingly thought of as a leader - You get to invest in better companies... etc.

The marketing angle is increasingly a way to get onto (and sustain your place on) this carousel.

Some ideas that have worked well for me in b2b/SaaS:

* If you're pre-product/market fit, just reach out to users via email, in-product messaging etc. You can incentivize them with Amazon gift cards as well. At this stage nobody actually needs your product so you'll have to do it by hook or by crook.

* If you're post-product/market fit then people actually _need_ your business. Once you make it clear that you're going to action on their feedback they're highly incentivized to help you out – so use the same strategies as above but make it clear what you'll use the feedback for.

* Set up automated surveys, especially ones that are unobtrusive in order to not create a shitty user experience – this allows you to baseline your product's effectiveness which is the first step towards continuous iteration. Eg last quarter we were at 3.3/5 satisfaction, let's get to 4.0/5 this quarter. These surveys are also a great way to find customers to interview.

* FullStory and Hotjar both allow you to view user sessions, highly recommend them as well.

The most important point: if you're an enterprise business, I highly recommend identifying the "best" customers that you have, building relationships with them, and favoring their guidance over others'. Once you hit scale all of your customers will want to give you feedback, but only some of them will have the wisdom/intelligence/creativity/whatever to have a great sense for what _you_ should build for _your_ business to succeed. When you find these customers, get them onto a customer advisory board / meet with them a lot as they will help you in the art of pulling a great product out of your market.

I continue to be really impressed by Datadog. They're in the very exciting post-IPO enterprise SaaS phase where they still have startup mojo + the resources of a large company + the need to continually grow and expand.

I feel for the teams that will need to compete against them as they enter new markets, although I expect that their forays will fail at a fairly high rate (as most product line expansions do).

IMO one of the keys to a platform engineering group's success (alluded to in this post) is having a mindset in which other engineering teams are the customer. Once you flip into this mode it becomes a lot more clear how your platform is really a product, and the platform engineering team fits much more seamlessly into the overall organization.

Our design team has churned off of all prior products and now uses Figma. I've consistently been impressed by the degree to which Figma appears to be completely trouncing InVision / Sketch / others with a superlative product.

The standard trend in enterprise software is towards oligopoly, with a few strong incumbents that struggle to actually kill one another as their products converge over time. Most enterprise businesses focus primarily on sales/marketing as they grow, rather than doubling down on a product that can kill incumbents. The fact that Figma has done both is really impressive and as an enterprise product head definitely something that I admire.