When I moved to New York City a year ago, I had a plan to become a product manager in a technology firm. After interviewing for PM roles at Pivotal Labs and Meetup, I met with Noah, the CEO of Percolate. He told me that they didn’t have a PM function and but that he was looking for hackers on the marketing team.
I jumped in with two feet — producing blog posts, case studies, white papers, webinars, films, and independent research — and learned a ton about marketing enterprise software. But I continued be passionate about directly building technology products. And in 2015, I finally got my chance to do it.
In January I started a new role at Percolate, working directly with developers and designers on the marketing team  to drive the release of our demo, a technology product our sales team uses to showcase the power of Percolate. I’ve learned how important it is to document the lessons you learn early on in a new role , so here’s my thoughts on four weeks of being a product manager.
1) It’s better to say when you don’t know.
Let’s face it: bullshit works. It’s often beneficial to give a confident, slightly vague response to a question than to waffle or look unsure. But as a PM, your answers lead to decisions and work that might be a huge waste of time if wrong. So you quickly realize that it’s critical to let people know when you don’t know the answer to something, to prevent them from going down a rabbit with bad intel.
2) Know your goals and tenets.
Whatever project or product you’re working on, it’s crucial that everyone agrees on what the goals are in order to allow people to make good decisions under uncertain circumstances. Having clear goals is like having a map and a good compass while exploring.
Know your tenets. Tenets are different from goals in that they are how you do something, rather than what you’re trying to do. I think in this project, our tenets have been assumed but not explicitly defined (we will maintain a careful continuity of the narrative, we will model the real product as much as possible). While this works for the most part, there are times where a lack of clarity of how we’re going to operate can lead to a difficulty in moving forward.
3) Always do the unblocking work first.
When I was doing mostly content marketing, it was easier to pick of items from my task list based primarily on what I felt like doing at the moment. While projects obviously had a variety of pieces to them, I had more flexibility in the order. With products, it’s often the case that other people can’t do their part until you do yours. Which means you better get that part done as soon as possible. Now, I’m constantly looking at the task list and thinking about which needs to come first.
4) Create the right sized task and group them well.
Products are nebulous. You have a basic sense for how they might function, but there are so many discreet elements, many of which have to work together. I’m lucky to have developers on my team who have worked on the tool for far longer than I have, and generally know how to pick off tasks that are right for their abilities and intelligently grouped together. Still, this is something I want to improve on – making the right kind of task.
5) Make the tools work for you
At Percolate we use Asana as our bug tracking / feature development / general task management tool. There are a million ways to use Asana – what do you bucket into a project? Will you use sub tasks? What tags, if any, will you employ? What does it mean exactly when you check a task is complete? I’m naturally wary of introducing too much process but without ongoing conversations and some structure, it becomes really hard to measure progress.
6) Progress is paramount.
On that topic, it’s incredibly important to track progress. We switched from having one big Asana “catch all project” for my main product to using smaller “release projects” and a major reason is because you can work towards completion on the release project. Seeing your competed tasks catch up to your total tasks is really satisfying.
The corollary to this is that backtracking or redoing work is the worst. I asked for some design work to be done and after I got it back, I realized I hadn’t been clear enough about what was needed. We ended up having to redo the work and I felt really bad for making the designer have to redo something because I wasn’t clear enough on my request. Every little thing like that causes the project to slow down and I have to be vigilant to not let that happen.
7) Watch for scope creep
Traditionally, the product I work on has been released in larger overhauls in a bit of a waterfall process. This sort of made sense in the past but because we had longer time spans between deploys, there was a tendency to want to add new features to the release, with the reasonable and accurate rationale being that it would be a while until the next release so let’s get it in there. This of course lengthened the time frame again in a vicious cycle. Scope creep sucks.
8) Don’t be afraid to experiment with process
As a way to counteract the issues I described earlier I’m going to try something a little different: 2 week sprints where we cut scope and ship *something*. My hypothesis is that the faster cadence is going to keep our morale higher, force us to be more disciplined, and help us to do ultimately do more. I’ve been wary of introducing unnecessary process but at the same time, I’ve got a hunch this will help us be more effective. Let’s see what happens!
9) Don’t forget about documentation
Because I work on the Demo, which is used primarily by the sales team, there’s a fair amount of documentation that goes into the product. How it works, what’s changed, etc. Of course you want your product to be as self-explanatory as possible, but functionality often trumps usability to some degree with the product I work on for complicated reasons, so remembering to build in time in the schedule for documentation, training and other issues is important.
10) Try to document in-the-moment decisions
Even reading that sounds obvious but hear me out. We have a pretty small team and our work doesn’t always start with a massive brief. We usually have a list of stated goals, screens, and a general outcome we want. We have to figure out a lot along the way. I found myself making real-time decisions that I thought “I really need to capture this decision (and the rationale) for later on. I’m experimenting with different ways of doing that.
 I wrote a post on the Percolate about how we’re structured — it’s one of the only marketing teams I know of with dedicated designers and developers