Prefer video to reading? Here’s my Skillshare step-by-step walk through of this.
In the past two months I’ve talked one on one with about 20 people who are interested in getting into Product Management. There’s a large range of experience/skills, but none have held the PM title. Despite giving everyone some different advice, my universal constant is that anyone looking to get into PM should do a small project from end-to-end.
Why do a project?
There are three big reasons that “do a project” is my first advice:
- It’s incredibly satisfying.
- It actually teaches you what being a PM is like.
- It’ll help you get a job.
Unfortunately, doing a small project isn’t always approachable.When I suggest this, I get a bunch of blank stares and questions like
- “well how do I get started..?”
- “how do I know if it’s good?”
- “but… I’m not a developer?”
So, this is the process I use for my side projects. It’s not all encompassing, and it isn’t exactly how I do my day job. There are definitely better resources for each step, but I hope having an outline will make the process more approachable for people without product experience, and particularly for those without technical experience. (Hello consultants, bankers, or others who aspire to work in Product!)
If you’re already a designer/engineer and want to get into PM, you probably already have your own way of thinking about problems and doing side projects. This may be interesting to see how a PM thinks through things, but will be less practical.
Start writing down your ideas.
Whenever I have an idea for something, I write it down (no matter how big or small or whatever it is). I tend to keep ideas on my Trello board. Right now, I keep stuff separated by website, writing, or art.
If you have a bunch of ideas you can write them all down at once. You can try to specifically come up with ideas, too. I tend to just wait until something strikes me, add it to the list, and then pull things off the list to work on over time. Where you make your list isn’t important. I started out by caring a notebook with me everywhere.
The hardest part for me is not falling into the trap of “that idea isn’t big enough.” Nothing is too small to get started in on – it’s actually better to have something small so you’ll be able to do it.
To say that tangibly, I wouldn’t write down something like “start my own jewelry line.” I would write down “design and make a necklace that looks like a swing for myself.”
The same applies for software: you don’t necessarily want something that’s a whole business. Something small is great. “Make myself a personal website,” “visualize my data from X,” or “create a web app to help my friends coordinate what to bring to brunch” would all be a reasonable scope.
Also don’t try to evaluate the ideas yet, just write them down! Once you get in the practice of doing them, you’ll be more likely to think of yourself as the sort of person who has new ideas for projects.
Incubate the ideas.
Writing something down is just the first step. I tend to keep much longer lists than I will ever end up doing.
Writing the idea down is a way to help it stick around and float in your mind. The idea of the project I’m working on now (/Energy) came up in an offhand Skype conversation with Nikki back in September. It stuck with me as I kept working on my other projects – and I kept realizing times I would want to use it. I’d continually schedule five meetings in a row, thinking “no, really, I can this time” and then end up exhausted.
Then, when I have a bit of free time, I meander through my list to see if anything really strikes me as something I want to work on right then. Since I’d been thinking about the /Energy idea, when I was going through my list and had some free time, it sparked my interest and I decided to work on it.
I like using Trello because I can add more notes when I see a blog entry or another product that really resonates with one of my ideas, I can add it in a comment. You can do that with whatever system you pick, though!
The important part this step is not getting stuck in incubation forever. If you’re excited about something – just start! Let yourself work on a side project that you’re excited about! It shouldn’t be something you’re “supposed to” do. You’ll never do it.
If you’re having a really hard time getting excited, you can just pick one and get started. You can always change your mind if inspiration strikes you later.
Frame what you’re trying to do.
Take the idea and start thinking about and answering the key questions:
- Who am I building it for? Is it for me? (This is a VERY good place to start for a first project). Is it for my friends? Is it for cake decorators? People who want a cat sitter to live in their house? (Picking a specific user group is good for subsequent projects – it adds a layer of complexity with talking to users and figuring out their needs).
- Why am I building it? I don’t like looking at my shelves on Goodreads. I want people to be able to find information out about me online. I’m bad at keeping in my mind my own energy level during the week.
- What’s the MVP (Minimum Viable Product)? For your website, you need a landing page. That might be minimum. For my /Energy project, I wanted at least to have my own updatable battery that texts me everyday (making it for anyone else is a nice to have, as is being able to see variations in my energy over time).
- What do you want to make after the MVP?
You can just write these things down in words – the important part is to think about it. Once you think you know what you’re doing, try to make a concise vision statement:
Craft a vision statement.
Figure out how to say what you’re making as concisely as possible.
- “A visualization of all the books I’ve read.”
- “A personal website that explains what I’m good at.”
- “An application that reminds me to check my energy level once per day.”
This is what you’d tell someone if they ask what you’re working on. It will also help you keep your focus.
In a PM job, this would be really how you’re selling something to the rest of your team and to the world. For something like Video Mode, I’d probably say “a way for backers to serendipitously discover Kickstarter projects that fit their interests.”
Figuring out how to express your idea succinctly and effectively is a very important part of being a PM
Make a feature list.
The feature list, user flow, and mockups all go hand in hand. You don’t necessarily need to go in exactly this order.
- What do you actually want to make?
- How can you break it up into smaller areas?
It’s generally good to have these prioritized. This isn’t necessarily a list of views, or of functions you’d write in the code. It’s just an idea of what you’d need.
This is easiest to explain with a concrete example, so, for Blank in Blank I needed:
- A landing page that let users pick a city and a profession
- A results page that showed the results
- A results page in case there weren’t any results
- A way for users to submit their own document
- A way for users to log in / authenticate (because of submissions)
- A way for me as the “admin” to approve things / get notifications.
If you’re doing something content-heavy rather than feature-heavy you could try breaking things up like that.
For a personal website perhaps:
- A page explaining who I am
- A page highlight my writing
- A page highlighting my speaking
Why bother to prioritize? Because some features are useless without others. You want to start on the most important things – there’s never enough time to do everything. A good example is for my /Energy project, being able to see a data visualization of “past Energy” is pretty useless if I never created a way to update my energy level.
When you decide not to include something, or de-prioritize it, you can also write up a short paragraph about why – this will help your memory and remind you of thoughts and concerns if you come back to it to work on later.
If you decided to work on something particularly complex, you can always keep track of features or smaller “tasks” in a separate Trello board. That almost always happens in formal jobs, because those projects are more complicated & have more stakeholders than small side projects. Even if it’s something small, it might be good practice to use a little bit of a system to track what’s done/not done/has bugs.
Draw the user flow.
It’s important to think through how people will actually be using your product. You don’t want to end them in a dead end because you didn’t consider how things connect.
Draw how all of the views of your app link together.
- If you have sign up, where are you re-directed to after you finish?
- What about after you log in?
- If you’re making a content platform, if you finish a piece is there a call to action at the bottom? Where does it go?
If you want practice wire framing a specific example, I always recommend the airbnb signup flow for hosting your place.
You can just white board this all out so you’ll understand and make sure it works.
Make mockups for each view.
Your user flow and feature list will help inform this – but once you have a good idea of what’s going on and what you’re trying to build, sketch out each individual page.
It’s easiest to do this with pen & paper or a whiteboard. Draw rectangles, but things in rectangles in about the size you want.
- Do you need a sign up button? Is it at the top, bottom, center?
- Does the log in button go in the upper right hand corner?
- Are results most of the page? Copy?
Just draw a picture of basically what you want for each screen. You can also tie multiple mockups together by putting them right in the user flow.
Here’s an example of Perry’s first drawing of the Kickstarter project page:
Do I need to make a specification/spec?
If I was doing a project for work, I’d end up typing this into one document:
- Why are we doing it? (high level goals, user scenarios).
- What are we doing? (feature list)
- What are any other lasting concerns?
- Details – mockups, explanations of what to do in error cases, etc.
For a side project, I wouldn’t do this. I can just look at my own wireframes and keep the idea in my head – I’m not trying to keep nearly as many people happy or on one page.
If you want to do it as practice, feel free.
Revise your work so far.
This is really just the beginning. You might want to take all of these mockups out and get feedback.
It’s also good to get feedback from someone else. At work it might be someone who works on a similar part of the product. It also should be your actual users. You could do paper prototype testing. You could do a heuristic walkthrough and see if they’re usable.
If you’ve actually gone through this entire process and want some feedback, you can send your work to me and I’d be happy to take a look. It’ll help me learn about how to revise this post to make it more useful, too
Up until now was all the work the Product Manager tends to do up front to start focusing on a project. It’s huge part of the Product Management job.
There a second big part: actually working with the designer and developer to get build is completely different phase of the project. This is the pretty exciting part, because it’s really great when you finally manage to finish your project and show it to other people.
I like to take my small projects end-to-end for the sake of learning more about visual design and development. It gives you an idea of the challenges that your coworkers face on a regular basis, and gives you some more credibility.
If you want to be a PM, I’d advise you do the same thing. You could also try to find developer/designer friends to work with you.
I’ll do a follow up post next week with some implementation advice for small projects. You can also definitely do some of this work & implementation in tandem, but while learning it can be easier to focus on one thing at a time.
Wait wait wait, I only read this far because you said this would help me get a PM job, but you still haven’t told me how to get a job.
I feel like why this helps with getting a PM job should be pretty obvious. So, seriously, go do a project. But, in a couple weeks I’ll also share some ideas about how to talk about side projects in PM interviews.