Time to read: 11 minutes

I have spent some time studying and improving my skillset as a PM. I have previously written about products, mistakes I’ve made and results from these mistakes but have never written explicitly about specific skills.

This page will cover things i’ve studied, notes and learnings. Use it if you also will be in a technical role focused on developing high quality products + using AWS + good development practices across the world.

I’ve previously ran a b2b saas which I am basing a lot of my experience on, and this might not be relevant for you. While researching I found a few good books one can read to accelerate their learnings if they haven’t done a lot of this before.

  • Cracking the PM Interview - a comprehensive book on how to interview well and land a PM role at a startup or big tech company
  • Decode and Conquer - a combination of interview prep and thoughtful answers to some of the most common questions.

I’ve read both. I’d suggest reading both.

Amazon Web Services:

I have used AWS extensively. If you have not, here are some things you will want to be familiar with.

EC2 - a virtual server in the cloud. similar to renting an apartment vs buying a house (this is called on-prem in software). You can “spin up” an “instance” in <60 seconds with an infinite number of options.

If you don’t know why this is important, don’t worry too much about it. If you aren’t actually writing code this will not affect you much.

ECS - a service that sits on top of EC2 that enables you to easily run docker containers at scale. You can set all of your config up and pretty quickly have 100 servers splitting traffic and restarting when they crash. You can do this manually without a nice GUI like AWS (jokes, Amazon GUI hardly works) but doing things manually is not what the cool kids do. (You know you’re in software when you spend 2 hours automating something that took 5 min to do manually)

S3 - storage for things you shouldn’t store in your database. I used this in our app to store thousands of customers job applicants resumes. The exact configuration was storing the primary key in the db and using it to look up the resume when a customer needed it. S3 gives you a link that takes you to your document and is easy to use. Don’t store images/pdfs in your database. Use s3 for that.

RDS - managed database as a service. I know 2 databases well (now that RethinkDB is dead, RIP). MongoDB (from when I didn’t know any better) and PostgreSQL. If I have a choice I always choose an RDS PostgreSQL instance. It just works, allows the standard config like VPC and is backed by Amazon. Lots of ways to innovate in product but the reliability of your database should not be one of them.

SES - simple email service. This is a reliable and cheap way to send a lot of email. If you currently use something like ActiveCampaign or Infusionsoft its quite similar (albeit, those products are better). Use this if you have negative budget and need to contact everyone in North America. Else, you should use a real email service provider to do your marketing.

Lambda - to make a parallel from accounting, this allows your code to be run just in time. If you ask for your lights to turn on, the code would run to turn them on and stop. This is different than something like ECS that typically runs your code 24/7. I have used lambda before to create a office meeting assistant. This assistant would book the next available conference room for me and send me an email confirmation of which it booked.

IAM - this enables you to be secure in how you’re enabling others to access resources in your account. You can create roles for specific assets and terminate accesss after the fact. You should be using this 24/7 and not using root log in. Don’t be that guy that is lazy here. Security is important.

ELB - imagine having 100 servers all running copies of your code. How do you nicely distribute that traffic based on rules (maybe evenly, maybe based on location, usage, etc). ELB (elastic load balancer) does that for you.

Route53 - this lets you take the ugly DNS records (usually an A record) you get from an ELB and set it up to be a nice and pretty URL like https://api.yancy.app.

VPC - similar to IAM, you need to be using these in a smart way. A vpc lets you secure your assets in a way that makes sense. For example, you will want your database to only be accessed from your code (+ your office). With a VPC you can do that. Otherwise anyone in the world could hack away at trying to gain access. You don’t want that.

CI/CD

CI - continuous integration. You want this set up such that while developers are writing code, they can easily integrate it back into “master” or whatever feature branch they are on, and confirm it integrates. If you are doing this well you might have 100 intergrations in a day.

CD - continuous deployment. You want this so that once all this brand new code is written and ready to go it actually makes it into production (or staging, etc) with very minimal effort. Maybe as easy as passing tests or an approved pull request!

You can use tools like CircleCI or Jenkins to do this. There are thousands of options. Your team might have one they are experienced with and if so, hit the YouTube’s to learn the basics. You can do so in a few hours.

AWS + CI/CD fits together so that your code is running without you thinking much about it, you can update the code and get it out to your users once it is safe to do so with very little effort. This is an incredible advantage today compared to 20 years ago.

Languages

This doesn’t matter a ton. If you are familiar with a few it will help. Otherwise, you probably won’t be able to add value to the organization here.

If you do not know SQL or are not technical that is a language you can get a working proficiency in a day. SQL is the universal standard to pulling data from a database. Want to know how many users signed into your app in the last week, great, a well written SQL statement can do that for you. I’d urge you to learn this ASAP. It slows your ability to think critically down if you can’t pull your own data.

Thinking

A common misbelief is that a PM runs the show. Having read up on the most popular resources I can confirm this is talked about multiple times a chapter it feels like. Depending on the organization a PM can have many different functions but it might be easiest to envision yourself as a navy seal.

A navy seal trains on a variety of different work outs, tasks (both mental and physical) so that he/she will be ready for whatever challenges come. I like to think of being a PM the same way. You do not get to choose what challenges will come but you can be well prepared for them when they do.

Some examples I’ve thought about:

  • partner api’s are unreliable and break often.
  • data is slow to be processed and causes value to be slow to see in app.
  • users just aren’t quite loving the product and are indifferent towards it.
  • users want to find contact data asap and admins want to track what their users are doing, when (very different features for both)
  • benefits of product are not out-weighting switching costs right now.
  • We can’t be feature complete without missing a deadline so what can be prune back to make it easier on the team to deliver

These are just some examples. You will have an infinite number more. The learnings are not to copy what I did, but to learn to think through and tackle these issues as they come up. A common term is referenced as creating “mental models” and thinking from “first principles”. I am more skeptical of these because they typically are used as a way to roughly say my thoughts are right and superior but to each their own.

As you think about products and development of them you will want to read some books. A few I’ve found particularly helpful are:

  • Zero to One by Peter Thiel
  • Thinking in Bets by Annie Duke
  • Software without Borders by Steve Mezak
  • Thinking fast and slow by Daniel Kahneman
  • The Black Swan by Nassim Taleb

If you read those you will be off to a great start of filling your head with a variety of ways to think deeply about the world, and thus, open your mind to different approaches that might be helpful down the road.

Projects

I’d also suggest finding time to work on side projects so you stay current on what teams are working with. This will really hone your product sense. I’d honestly approach these as real businesses. Real products that need to be sold. Build 1 and sell it. Build another and sell it.

This will force you to do a few things.

  • Actually ship something
  • Actually sell something

If you can get into a muscle memory of doing these actions you will be way better off. How often have you started something and not finished it? This is a major weakness of mine and I have been improving it by forcing myself to do these things above. I specifically keep an asana board where I track ideas, pains and potential solutions.

As I do that I might decide to build 1 of the 50 I come up with in a month. But, when I decide to build 1 I am going to ship that piece of software (usually during a 48 hour weekend). You might not be able to follow the exact same cadence. But follow as close as you can and you’ll be adding valuable skills to your toolbelt.

Questions

The value you deliver will be a function of the questions you ask.

def value_delivered(q1, q2, q3, q4, q5):
      value = q1 * q2 * q3 * q4 * q5
      return value

The learnings from each question build on each other. It is not addition. It is multiplication. So the more you ask the more you learn.

If you approach everything you might build or sell by specifically focusing on questions you will have learnings that enable the value to skyrocket. Ask more questions than you think you should. Ask more questions than you think is humanly possible. Bonus points if you record the conversation. Anytime you don’t know what to say next, just say “What do you mean?”.

If you build muscle memory of this you will understand your users and customers and team members and leaders way better than just making assumptions about what they might be thinking.

I’ve also written about 7 product mistakes I made. You should read that post next as it continues on the summarized learnings from here. The link is https://kameronkales.com/thinking-about-products/.

I am active in the PM HQ slack and asked about resources to prepare for technical interviews and the group aggregated these links:

  • https://blog.gruntwork.io/5-lessons-learned-from-writing-over-300-000-lines-of-infrastructure-code-36ba7fadeac1
  • https://github.com/trimstray/the-book-of-secret-knowledge
  • https://github.com/igorbarinov/awesome-data-engineering

Thanks for reading. I will update this with nicer formatting and more information down the road but for now, use it as a reference guide on getting started thinking about products.