Category: Becoming a PM

The goal of this experiment is whether we can be smarter about building product because we pay more attention to how we do it.

Everyone I know out in the Valley is quite process averse. Folks write against it, preach against it, and fight against it as much as possible. We’re not big enough to need it or there’s nothing broken with our product development cycles are the main excuses I’ve heard though there are others.

I’ve been trying to figure out why this is a ruse.

I’ve seen where the small team fails without a process. I’ve seen where the perception of success is simply a lack of visibility into what’s possible.

And so I’m putting my money where my mouth is.

We’ve talked about this a lot amongst the product team. Betsy started it off by putting a more visible design process on the table. The design team has picked it up by putting a work board onto a wall in the office. On the product management side, we’re creating a one page spec sheet. In one page, we want to define business requirements, use cases, core functional requirements, and a success criteria. It involves being brief, being straight forward, and properly building a living document.

The outcome should not be a cumbersome set of hurdles to get things out the door. It should be a common language for product development that helps us become great at it.

I met with a cool cat today for some coffee. We were introduced by Jason (check out this post), and talked about being a PM, what that means, how to represent oneself well on a resume, and the like.

I told him about a role we’re looking for that involves a lot of storytelling, and it made me realize how hard it is to represent storytelling as a thing on a resume.

I remember last year when I was hiring the first two folks that I found how I’d talk to pretty much every resume that came through just to get a read on whether I liked the person or not. I think the reason was as simple as I had no idea what to look for in a resume.

Since, I’ve realized that the value of a resume is mainly in understanding how people see themselves. When you challenge someone on a role that is labeled as Project Manager applying for a Product Manager job, then they can immediately bring up points that had nothing to do with moving a ticket between working and complete. And yet, they took a job called Project Manager, and didn’t think about the label that that put on them.

Byrne told me once that the role at TokBox let him re-establish how he marketed himself for the future. That’s a really forward looking approach to taking a step back, and then being able to jump into a gig knowing what you’re hoping it does for you.

In that regard, titles are really important regardless of what other folks in Silicon Valley may say. It has nothing to do with who you are, and yet everything to do with who you could end up being.

So back to the point – whether your resume says it or not, if you’re a great storyteller, who can speak developer, and help folks fall in love with a real-time communication platform, then let me know.

In search of storytellers 🙂

I jammed with Jason Monberg today who is a really cool cat who came into my world view through Ian. Jason and Ian worked together at MarkLogic.

Jason has a consultancy that’s quite cool. They do both product development as well as product strategy, process consulting, and the like. He’s got a cool office space, and he’s been jamming on starting a PM meetup there.

We talked a lot about what’s valuable in those meetups, and this is a topic I’ve thought about a lot. There is no StackOverflow for product management. Product management is also a lot of things at a lot of places. Finding good templates is hard. Finding tips on actual execution and tactics is tough. Figuring out strategy from insanity requires real mentorship or kinship at times… and neither is readily available.

Product managers need a community. One where they can trust each other; openly discuss how to better the craft; and ultimately feel less lonely when ganged up on by the world.

Jason and I talked about this a lot, and how to pull it off. Hopefully there are some really good ideas that he’s got now to run with because if we can pull this off, then I really believe that the craft will take a big leap forward.

I had an absolutely superb meeting today with someone on the team about the tidal wave that has swept product development – data.

We talked a lot about how it has become a must have skill set in the Valley, and where we land on that scale (read: way behind). I kept the conversation going in my head tonight, and it really has forced me to ask where as a team we need intuition and where we need to be data driven.

So I did what any logical person would do, and I hopped on Quora to see what others have asked, and what answers have been given.

I think one of the benefits of Quora is also a bit of a downfall. Folks get requested to answer a question, which brings experts to the topic. BUT. It tends to bring a very specific answer set as well. In this regard, I got inundated by religious zealots swearing that there was only one way, that way was data, and Reis was his prophet (ok, I made the last piece up, but you get the idea). There are few folks who defend intuition because it has no tangible way to prove success. Much the opposite, there are way too many failure cases to the contrary.

So Quora failed me.

Instead, I dove deep into our platform, and came out the other side realizing that we need to be is an intuition based team where data acts as the final scorecard. Our intuition used to just come from gut, but today we have enough customers that we can soft test anything. Further, the leaps of faith are quickly becoming hops, and on the horizon will be even less contentious. Why? Because first customers will say they need it, and then we can prove they use it.

And yet the big ticket item of what and where is still a task for our imaginations. I like that. A lot.

This blog post is a ramble more than a thought, but nonetheless I’m really excited about our product development future. Numbers and prayers both have a big part to play.

We’ve just stated a new weekly lunch event on the product team where we pick a relevant topic and jam on it. We talked about a new strategy at one, and design process at the one today. It’s an attempt to cross pollinate across the team best practices, new ideas, road map pitches, and the like.

One challenge in the office is that we’re grouped into teams, but that doesn’t guarantee that we’re working together towards a common goal. Sometimes the issue is opaqueness, and sometimes poor communication. Not enough time to coordinate, a lack of context, or even an inability to relate all lead to an inability to align.

But I just don’t buy it. We have common customers, and a common end goal. Within that we’ve got to find a way to create a common language. And that’s the goal of these lunches.

I hope that in three months time our designers have a clear vision of the platform and how they’re shaping it.

I hope that the larger team has a better visual of what we’re building because we become better storytellers.

And I hope that these exchanges become a high point of everyone’s week.

Because the best part of being a team is winning together, and I think this will help get us there.

I wrote this as a note to someone special earlier this week, and I really like the message. I’ve decided to share it in an edited format here.

Folks leave.

It’s sad because it feels like somehow the system failed. But we don’t think that about death. When someone dies, we create room for someone new to be born who brings a newer, and hopefully better, perspective to who we are, what we do, and how we do it.

Death’s inevitability gives us a reprieve. And yet even without death everything comes to an end – inevitably. Hitting streaks, consecutive quarters of profitability, periods of peace – none can last forever.

In a static system, there is neither death nor birth. Culture can become static. Endings act as a wake up call that we cannot be static. The lesson is to not hang on to being what we were, but, instead, create an energy to become.

Part of the journey is starting to let go, and letting the culture be carried by others. The others will do a great job because we choose them, and make sure they do. The actors who see that transition, and decide it’s not for them make the best choice for all in leaving.

The end game doesn’t change. But we do.

We had a really great demo day today.

It’s the beginning of celebrating lots of small steps. At the end of the road, I think we’ll all find it was a journey worth taking. And through it, we’ll have lots of stories to tell 🙂

The tradition of celebrating small success isn’t new at TokBox, but I do think it’s a bit forgotten. One of the first things that Yang did when he joined back in ’09 was bring in an agile methodology. We become three small teams, and we did a lot of really good work in our units. Each unit then showed off its work in a demo day. This is par for the course for an agile team, but something we’d never done before at TokBox. The genius of demo days is that a scrum master can make his team look great for even the smallest things because the whole point is to accomplish all of those little things that led to the train leaving the station and going into the world.

I remember that feeling very vividly of having an awesome demo, and sharing with pride the work we’d accomplished. We did bi-weekly releases, and so it was never a huge amount of work. It wasn’t a platform company, and so there wasn’t a big partner acquisition to celebrate. There was just our hard work to point to, and take pride in.

Small victories bundled together become big wins for the world to see. I can’t wait to share those too!

I have two distinct phases of my career at TokBox split between working in the engineering group, and then transitioning into product once we launched OpenTok. Building the prototype of the OpenTok platform is both the marker of the transition, and the high point of my career in engineering.

I call it the high point because it was a period where I felt like I was locked in, and able to execute at a fantastic level. Context-switching between coding the project, evangelizing the API,  and doing my day job was as efficient as could be. By the end of September, when I left to get married, I was on a high that I genuinely appreciated after two years of sloshing through in a bit of  a lost state.

I fully transitioned into the product team by March, and was thoroughly getting my ass kicked the next day. Right back in that lost state, I got bullied into decisions I didn’t agree with. I didn’t understand how to successfully create accountability, deliver ownership, motivate, or execute. And that didn’t change for some time. It was de-motivating, and difficult, but I found a bunch of small wins along the way to help push through it. Small wins are the flotsam of a drowning PM, that’s for sure.

But then funny things started to happen. I stopped feeling bullied, and instead turned meetings into really intelligent conversations where folks could disagree. I found the guts to suggest crazy ideas, and bold initiatives. I started defining the discourse and language of my meetings, and then my colleagues, and finally my company.

And then I arrived back to that high. And let me tell, after the slog of everything else it’s a good place to be.