Stay in touch with PAH.

Follow us on twitter @productsarehard and sign up for our mailing list to stay abreast of our events.

PAH13 Wrap-Up

PAH13 is in the books.  By all measures it was a success. Thanks to the over 200 people (30% more than PAH12) who made it a great day. Early feedback has been overwhelmingly positive. Particularly encouraging was how many teams came together, and we had multiple people say they wish they’d brought the people they work with every day. Next year we will put more even more focus on making it valuable for teams to attend.

After PAH12 we wrote a postmortem on our first attempt, and this year we definitely felt like we’d made it up the learning curve quite a ways. It helped that we did it at the same venue, though we filled the room, so we’ll need to decide if PAH14 can fit in that space.

Below are links to the slides from the speakers along with any supplemental links the speakers provided us.  Also, Carolyn Wales has agreed to let us post her personal notes from each talk (along with delightful little sketches of each speaker).

Thanks again to our lead sponsor, GitHub, along with Klout, Zendesk, Pivotal Labs, and Chirrpy.

We will update this post if we receive additional supplemental materials and/or when we get audio/video of the talks.

If you have any feedback we’d love to hear it.  Get in touch!

Be sure to follow us on Twitter (@productsarehard) for updates on future PAH events.

PAH13 Janice Fraser

JANICE FRASER

PAH13 Sonny Vu

SONNY VU

PAH13 Sarah Rose

SARAH ROSE

PAH13 David Charron

DAVE CHARRON

PAH13 Charles Hudson

CHARLES HUDSON

PAH13 Hiten Shah

HITEN SHAH

PAH13 Sue Bethanis

SUE BETHANIS

PAH13 Judd Antin

JUDD ANTIN

PAH13 Indi Young

INDI YOUNG

PAH13 Ian Kennedy

IAN KENNEDY

PAH13 Chris Lindland

CHRIS LINDLAND

The Five Pillars of Product Management

A few years ago, as I prepared to leave a product manager position, I trained a junior member of the team, someone new to the role of product management, as my replacement. I told him the role comes down to the following five elements.

Gather

A huge part of product management is simply knowing what’s going on — what people do all day as it relates to the product, what kinds of things they wish they could change, and how the various constituencies interact. While most product managers have plenty of good ideas on how to improve the product, gathering ideas from and identifying problems in the rest of the organization are just as important.

Synthesize

As ideas and issues emerge, a product manager must create connections where others do not see them. Two groups in an organization may have two very different problems. A product manager should be able to find a way to make a single, better-abstracted view of the underlying concern. Synthesizing also involves creating named themes, initiatives, and goals for a product. Never underestimate the power of synthesis to create common understanding and bring sanity to the chaos of “line item” requests. Synthesis is also instrumental in winning the hearts of product team members.

Prioritize

Choosing what is most important is an art. Deep understanding of business strategy, market realities, and resource capabilities is key. Knowing what’s hard vs. what’s easy and what’s of broad vs. narrow value helps to create a prioritized list of the various tasks to be completed. Given infinite time and infinite resources everything would be possible, but in the real world, making the hard choices (or, more importantly, helping the rest of the organization make the hard choices) becomes one of the central functions of a good product manager.

Define

A product manager must own the detailed definition of what the product should do so that engineering knows what they will build. This involves plenty of documentation, though much less than you probably think. Document only as much as you have to. Don’t create detail for detail’s sake. With web-based software the need to be quick and iterate frequently makes it essential to move forward with imperfect information and adjust as you go. If you’ve been an engineer or worked closely with engineers, you know the unique horrors of changing the spec and the dread of feature-creep. Part of the reason for the rise of agile methods is that rather than constantly reacting to attempts to get to a “finished” spec of a project (only to see that spec change in the middle of the cycle) engineers started to simply build the dynamic nature of requirements into the system. “Define” does not always mean writing down as much as being the Source of Truth.

Shepherd

A big part of my day as a product manager involves, quite literally, walking around the building. Keeping all of the balls in the air is a critical part of product management. In most organizations there is nobody else who sees all the various pieces and how they must fit together. Many product efforts require coordinating distributed efforts towards a single destination (and doing that over and over again). In my world, having the engineering “done” is only about 2/3 of the process. Once the actual “product” is at a finished state, packaging, documenting, training, and distributing all remain.

When I first put these 5 elements on a white board I wrote the word “CONTEXT” next to them. Ultimately, you must undertake all of these activities with a full appreciation for the business as a whole — the goals, strategies, capabilities, culture, and, most importantly, the people.

Product is a curious function. It is often under-appreciated, yet it is also the domain of some of the most powerful people in Silicon Valley. Product people must be generalists while also obsessing about small details. They must cross cultures within their organizations. They must be able to step outside the organization and sit on the same side of the table as the people for whom the product is made. It’s a hard, rewarding job and it’s the glue that holds many great organizations together.

[For more product wisdom from a host of thinkers and luminaries, join us at the Products Are Hard 2013 conference. Register now.]

Choosing a Technology is Choosing a Culture

Which technology is best to use in launching a new site or web application? There was a time when I would answer this question by getting into the details of the various features and performance characteristics of a given platform, but over the years I’ve realized it’s really not a technology question; it’s a people [...]

Continue reading...

Conferences Are Hard

Having had a week to recover from our first Products Are Hard conference, here are a few lessons learned. Not all of these lessons are generalizable, but giving a flavor for the behind-the-scenes is true to the spirit of the event. In no particular order: Cash flow can be tricky. When using Eventbrite you don’t [...]

Continue reading...

Strategy and Negative Space

“Keep your options open,” my mom used to say to me. Perhaps that’s good advice for a 12-year-old, but it’s terrible advice for your new business/product. Every company wants a strong strategy, a strong brand, and loyal customers. Ask a room full of decision makers if they want a clear positioning with their target market and [...]

Continue reading...

Mobile App vs. Mobile Web

We’re often asked about the relative merits of building a native mobile app versus spending the energy on a mobile-specific version of a web site. This question is most relevant when the content of the app is similar to an existing web site, but the situation comes up often. The case for native apps We [...]

Continue reading...

Chairs with Wheels

A former colleague once told me a story that delightfully illustrates the nature of business decisions relative to technology: Years ago he was pitching a big consulting project to a major telco. The telco had put out an RFP to various development shops asking for help solving a classic problem — they had a number [...]

Continue reading...

Un-human Experience

A few days ago I advocated using the word “human” in place of “user” when thinking about crafting experiences. In short, such language would make it easier to remember we are making things that people will enjoy or value, especially in relation to the Minimum Human Experience (as opposed to the Minimum Viable Product). Rather [...]

Continue reading...

Human Experience

I’m hardly the first person to complain about the word “user” to describe people who do stuff with software. But, in the “User Experience” community it is rare, at best, to see anyone questioning what the “U” in UX stands for. Call it quixotic, but I think the term HX (human experience) would be much [...]

Continue reading...

The Rotating Dessert Tray

Object lessons on experience and design can come from unexpected places – in this case an episode of This American Life recorded in a 24-hour period at the Golden Apple diner in Chicago. Picture a dessert case.   On the day the This American Life crew was in the Golden Apple the motor in the dessert was [...]

Continue reading...