Jen Granito Ruffner

About: Jen Granito Ruffner is a product manager driven by helping people be more productive & extract more value out of social networks. In her past, she’s worked at AOL Instant Messenger, LinkedIn, Zynga, Myspace, & Tagged.

She has launched LinkedIn’s news, sharing, and events products; Tagged’s (mathematically) viral registration flows, some of Cityville’s largest revenue generating and engaging features & more.

She is currently leading product at Kifi; focused on building tools and a network to  retain your team’s web centric knowledge management.

In addition to hard problems; she also enjoys ping pong, wine, poker, softball, travel, & cheese.

On the web:

Kifi 

Twitter

Medium

---

Select questions and answers from the AMA:

What PM tools do you currently use at Kifi and what tools would you recommend to PMs at other companies?

I LOVE tools that make me and my team more productive. Overall I think that the hardest part of the job is to first figure out  a process that works for your team.  Sit in a room and walk through a development life cycle and almost playtest what would happen with different ideas, tasks and stories from conception to launch / analysis.  Then throw in some wrenches; say midsprint, you start to see that you’re going viral in a community that requires a bit of a different shift; how do you address that? 

Once you have the process figured out; it’s easier to select which tools you want to use to help facilitate that.  

Here is a library of some of the tools that I personally vouch for  https://www.kifi.com/jen/helpful-tools-for-product-managers

My favorites are Trello for high level ideation (because I can bucket features into problems / or user stories). UserTesting for getting early feedback on ideas. Asana for actual implementation because it allows you to have the same task in multiple projects. Mixpanel or Amplitude for metrics and heck I’ll even throw in Instacart for those random beers that you realize you need at 8pm on a Thursday night.

What are some effective methods to evaluate what problems to solve (ie. what products to build)?

I think there are 2 ways that you can effectively evaluate problems:

— Start from the problems; Come up with the list of problems and make sure they have an addressable market. Even better if there isn’t much competition. Then brainstorm solutions. Run those ideas, or better yet prototypes by the addressable market; get feedback. Rinse wash and repeat.

— Start from the features and tools you have: If you’re an an existing start up and you have some assets, it’s useful to just start by listing the stuff you have, bucket them, and reorganize those buckets. Noah Weiss from Google, Foursquare, and Slack did this well when he had to make the difficult decision to split Foursquare into two different apps  https://medium.com/foursquare-direct/the-lego-block-exercise-4c7d60eeb38f#.3bg4aiye7

In your product roles thus far, which companies have been your favorite and why?

If I have to pick 1 company I would say that working at LinkedIn was my favorite.  

—  I joined when it was in a sweet spot. The company had established product market fit so it had significant users to be able to experiment, but it also had a lot of huge problems that needed to be solved.  It was a great time to dive in and work on some really interesting problems and features.

— The team was and is very smart. Some of my best professional contacts came from that company. As Jeff Weiner liked to say, we “drink our own champagne” and I’ve managed to maintain a tight network from this job.  I’m currently working at Kifi where the CEO was my new engineering partner at LinkedIn.

— The problems were AWESOME. I reported to Allen Blue, a brilliant product strategist and cofounder, that was in charge of getting people to come to LInkedIn more often than when they accept a connection request or are looking for a new job. It was a wide problem with lots of potential.

—  The process & team structure was set up to be autonomous and help you ship. Until the company hit around 500 employees, this worked VERY WELL.  There were 4 product silos:  engagement (newsfeed), core (profile & home page), revenue (job posting), data tools (People you may know). Each team was pretty much it’s own unit of product & engineers. The only group that was unified was design. Designers would rotate projects every 6 months to make sure that learnings were cross pollinated throughout the organization. Within  a silo; a PM, designer, and engineering lead were involved in every single part of the development life cycle from idea conception to launch. Wider parts of the product, engineer, marketing, QA etc. teams were brought in as needed; but those 3 core people from key disciplines allowed us to keep it small, make decisions fast and make sure that the appropriate checks and balances were in place before moving forward.

How does your product role differ based on the size of company you are at?

— When you’re in a small company the bottom line is that you need to provide ROI.  As Ken Norton says, the PM role is the most disposable. Hopefully you’re exactly what the team needs (a growth hacker, a visionary, a QA tester, an analyst). You generally need to be a jack of all trades, have a drive for learning on the job, & be an active listener. If you learn by doing, this is a great place to be.

— When you’re in a large company you usually get a chance to specialize in one of those areas; for example, focusing on developing a brand new product or looking at data & talking to users to iterate on an existing one.  You’ll also get more of a chance to see how things work at scale, both features and process. If you learn from other people this is a great place to be.

I like to switch between the two.  I get antsy after being at a small place and want to focus on 1 problem for a long time.  Then I do that for a couple years and I end up wanting to build something from scratch.

What do you typically find being the biggest roadblock when it comes to getting a product shipped?

The hardest part of getting something shipped is saying no. Distraction comes in all shapes and sizes and is often disguised as a beautiful muse; some great user feedback, a competitor that just copied one of your features, an investor who wants a feature for himself.

Recently I’ve started to pause for a few seconds before talking whenever someone comes to me with a distraction. It allows me time to really think and categorize something before I proceed.  

In order to do that it means you need to have a clear goal or OKR or problem that everyone is trying to solve. Anytime something attempts to hijack that, revisit the core question. When you think you have feature bloat or need to cut some stuff in order to ship faster, revisit the list of features you have left and try as hard as possible to figure out what isn’t going to really move that needed. This is one of the hardest things that you’ll have to do in your job.

What advice do you have for someone trying to transition into product management in tech from a non-tech industry?

Overall I think a PM is a PM is a PM; no matter what industry and it’s sometimes even beneficial to switch around for both your personal skillset and that of the company that is going to inherit you.  I was offered a job at Wealthfront specifically because I didn’t have a lot of finance in my background but I knew social. Back to Ken Norton again; he really sums what a good product manager “smells like”  https://www.kennorton.com/essays/productmanager.html 

I sometimes get asked this as well as “Do you need a technical background to be a product manager”. Personally, I’m a marketing major who loves to learn. With each job I usually pick up a technical skill to add to my portfolio; html, css, sql etc. I take Coursera courses to always be improving. The bottom line is that I make sure when I get into a meeting with an engineer, they aren’t explaining things to me. Usually this means reading the API documentation that they may be developing on (ex. Kifi just did a great slack integration) and I read it to try and understand what we can do with the permissions and information Slack is exposing. Come to the table with the bare minimum knowledge you need so that you’re not being taught by them. It’s OK to ask for help with something your unfamiliar with, but hopefully that happened ahead of the decision making meeting.

Can you walk through your process for determining the features to build in e.g. a given quarter?

— At Zynga, product managers were handed OKR’s from execs. We knew exactly what #’s we had to hit and quarterly, we would sit in a room with game designers to come up with features that would hit those goals. Often times the conversation would be more based around what viral channels could be used to tap get the traffic we needed. Or what gaming mechanics could squeeze out the most revenue we could from players. Then we would add fiction on top of those mechanics. It was more like one huge math equation we need we have to build and then paint a picture on top of. We would then do expected outcomes (using boatloads of comparable data available) to estimate how close those features would get us to meet that goal. Generally speaking you would get within +/- 5% of your forecast. This made planning the roadmap a bit more systematic.

— At LinkedIn,  I was on the engagement team so we were handed problems; wide / large problems (a bit different from the revenue team) and we didn’t have a TON of data to use to support our solutions. We did the best we could by studying competitors, debating internally, and getting info from focus groups / user research  to figure out a good plan. Because there wasn’t much concrete to go on; it involved a lot of communicating, listening and/or selling to people within the organization.

— At a small startup, a lot of it is about speed more so than planning. When you don’t have a ton of users, you can’t plan too far in advance. What can you do quickly that will help us prove or disprove a hypothesis. List the hypothesis and then do whatever you can as fast as possible to refute them.

All of these different methods require 1 thing; accountability. Make sure that you have valid data or learnings to share what you’ve done. This will help inform your next planning cycle and also help you build trust with your engineers because you followed up on what they worked so hard to build.

---

Interested in being part of the conversation with the world’s top product leaders? Check out future AMAs in the Product Manager HQ community.