Archives - Products Are Hard

The five pillars of product management

March 11, 2013 By Nathan Dintenfass

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.

Choosing a technology is choosing a culture

February 27, 2013 By Nathan Dintenfass

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 question.

The issues are: who is going to build it, and who are you going to want to hire to continue to build it. Anyone who has been around software engineers (or any engineers) knows that a truly great engineer is worth many mediocre engineers, so if you’re starting a technology-intensive business, it’s critical that you be able to attract high caliber people. For instance, Adobe ColdFusion (formerly Macromedia ColdFusion, formerly Allaire ColdFusion) is an extremely productive platform for building web applications — in terms of getting something done quickly it’s great, but good luck finding great engineers who want to work with ColdFusion. Deserved or not, ColdFusion has a reputation in the industry for not being a “real” programming environment (there’s a whole other discussion to be had about the perversely inverse relationship between the ease-of-use and productivity of a programming environment and the credibility it receives in engineering communities). Most software developers wouldn’t want to be forced to work with ColdFusion for fear their other skills would atrophy. This is not a statement about how good ColdFusion is as a technology; it is a statement about the realities of putting together a team.

This is a nuance lost on a lot of entrepreneurs and managers who haven’t done hands-on coding before — the tools you choose define the nature of the team you will build moving forward, and in most cases it’s extremely difficult to switch gears. To be fair, this nuance is also usually lost on engineers, who can easily burn a lot of cycles debating the merits of Ruby vs. PHP vs. Java vs. ColdFusion vs. every other thing. In the end, the tools listed here, among many others, are mature enough that they can all serve well to create web-based applications. Some might take longer, some might not scale as readily, some might not integrate with other technologies as easily, but from the standpoint of “can it be built in a reasonable amount of time and be production-ready and reasonably scalable” the answer is yes in all cases. The best technology to choose is the one that creates the culture you want.

Conferences are hard

May 8, 2012 By Nathan Dintenfass

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 actually get the money from ticket sales until 5 business days AFTER your event is over, but, of course, you need money up front to secure the venue, food, A/V, etc. If you don’t have a giant pool of cash hanging around this can create a sticky situation. We were able to cover the financing, but in talking to others we find people can be surprised by this issue when planning their first event. There are alternative registration systems that will let you get at the money before the event is over, but that generally requires setting up your own merchant account to process credit cards.
Costs
The cost of putting on an event can vary quite a bit. Food is typically the biggest variable cost as x feeding people a meal is much less than $25 a head (and often considerably more). The venue, in general, is the largest fixed cost. Once you get above 100 people there are only so many venues that can work at all, and above 200 people puts you (at least in San Francisco) into another pricing tier. Most of the venues that the tech community uses in San Francisco that hold ~150-300 people run $4K-$8K (some even more) for a day. A/V rental varies depending on the level of production value you’re going for. We rented A/V equipment and staffed it with our own people, so it was a minor part of the overall cost, but if you want highly professional A/V that is run by professional staff you could be looking at $10K just for that.
The Venue
We really love the room at the Hotel Whitcomb and find the hotel to be charming. That said, some people felt the neighborhood was sketchy and are more used to shinier digs for professional events. You can’t please everyone. The other nice thing about the Whitcomb is they require a very small deposit up front and don’t charge extra for tables and linens, though you do have to use their catering for all food and drink, so you have limited flexibility on that front (but their prices are fairly reasonable). We had a great experience working with the Whitcomb staff. They were accommodating to our last-minute changes and didn’t nickel and dime us.
Details, Details, Details…
As with any product the details make all the difference in a conference. There are so many little things that come together to make the entire day coherent and as first-timers we missed some and had to scramble with others. Thankfully we had a great muse to help us out who had been there, done that. Just a couple of the many little details were printing the schedule on the back of the name badges and putting the Twitter hash tag on as many slides/surfaces as possible.
Pricing
Our pricing was $299 for early bird and $399 for regular admission. We were told repeatedly that our pricing was “very reasonable” which we took to mean we could probably charge $100 more next time and still not be considered “expensive.” From what we heard, almost nobody chose to not come due to price, which for a first-time event is great. Of course, there are classic supply and demand dynamics at play here. If the event becomes so popular that it sells out in a matter of days our pricing likely won’t be so “very reasonable” next time.
Marketing
We tried a lot of different ways to get the word out about our event. We spent $1K on LinkedIn ads that targeted only people with a specific set of job titles that are in San Francisco. We spent a few hundred dollars on Facebook ads targeted similarly. We spent a couple days filling out all the various forms on event calendar sites. We paid a couple bloggers for ad space. We reached out to many more bloggers to write about us (some did). In the end, we can attribute only a small percentage of our ticket sales to any of those approaches. What did work? Twitter. We asked all of our speakers to tweet about speaking at the event (and gave each of them a custom discount code). We used Buffer to queue tweets that mentioned our speakers (some of them RT’d us when we did that). We mentioned people we think are just interesting product thinkers in our tweets. We gave lots of our friends custom discount codes and asked them to tweet about it. We did similar things on Facebook, but from what we can tell Twitter dwarfed Facebook in terms of influencing actual purchases of tickets. We also sold many of the seats through direct invitations sent to our friends and former colleagues (all of whom received a custom discount code that, in some cases, brought whole teams from their companies). Not shockingly, it took many tries to get some folks to actually register for a ticket, and in most cases we were thanked for the reminders. If you’re not a natural marketer it can feel uncomfortable to be “spamming” your friends and colleagues, but our mantra was that if you don’t feel like you’re being annoying you are doing it wrong. We found the old adages are true that people need to be exposed many times before they buy, so when in doubt you just need to pummel every avenue you can think of to get the word out. Our hope is that next year we’ll be able to start with the attendees from this year, which should get us a critical mass of tickets sold.
Speakers and Panels
We received a lot of very positive feedback about the speakers at the event. The keynote addresses both got rave reviews. People were less crazy about the format of the panels, though, interestingly, we had some people love some of them and others hate those same ones (and vice versa). Next year we will likely scrap the panel format and either do all individual speakers or set up a more engaging multi-party encounter. We’re toying with the notion of setting up a debate-style format where two people are cast on opposite sides of an issue up front. Overall, we felt like the pacing of the day was good. Some speakers could have happily used a bit more time, but as they say, “leave ’em wanting more.” We have also talked a bit about mixing up the day more to have some kind of hands-on workshops or other breakout sessions alongside the speakers, but that creates a much more complicated set of logistics and is in many ways harder to make good.
Just Do It
We had talked about doing an event like Products Are Hard for over a year before pulling the trigger. It took an enormous amount of time and emotional energy. Putting on the event was very satisfying, and once we decided to do it we pulled it together very quickly (8 weeks elapsed between our first emails to people to feel out the idea and people taking their seats at the conference). The first time you do an event is always the hardest (or so they tell us), so if you have a great idea for one don’t keep putting it off.

If you want to hear about our 2013 conference the best way is to follow @productsarehard on Twitter.

Strategy and negative space

February 9, 2012 By Nathan Dintenfass

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 you won’t get many saying no. If you press them to abandon some options and stand for something specific in the minds of their customers, the conversation gets awkward.

It’s easy to spend a lot time coming up with good ways to describe what we are — we can talk to potential customers about their needs, we can fuss with marketing copy ad nauseam, and we can generally convince ourselves that the path we are choosing is correct.

The most powerful way to carve out a strong position in a market is to choose what you will NOT be. And I don’t just mean making a mealy 2×2 in which you are “high-high” on some rigged axes. No, the essence of good positioning is to choose the thing you won’t pursue that will be a good option for someone else.

In some cases this is as simple as positioning against an existing competitor. In most cases it will take hard decisions because the human instinct is usually to keep your options open. These decisions aren’t irrevocable, but they do require a commitment from you and your team. So commit, and don’t listen to my mother (in this case).

Mobile app vs. mobile web

February 1, 2012 By Nathan Dintenfass

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 find that iOS remains the dominant app market, so some of these points are specific to that platform.

Idiom – The difference between a native app and a mobile-optimized web experience can be closer than they used to be (Facebook is a good example of this), but it will always be hard to replicate truly idiomatic device-specific experiences smoothly with a browser. These differences can be very subtle, but they can be critical to how often people will want to use the application, how they will feel while using the application, and what they can accomplish with the application.
Intimacy – The Web is a big place, and the web browser is a generic tool that people use for all aspects of their online lives. Our phones are intimate. They go everywhere with us every day. The apps we have on our phones are part of that intimacy; they are a set of symbols that represent our interests, chosen specifically and intentionally. Once your app is on the phone it becomes, in a small way, part of someone’s identity. A website, however beautiful on the phone, doesn’t have that kind of relationship.
Push Notifications – Push notifications give your communications an immediacy and urgency – this can be easily abused, but a web site will never be able to create that kind of intimate call to action.
Badges – The little red numbers that appear in the corner of an app’s icon when something new is available – these are really a sub-type of push notification, but the experience is different enough that it’s worth thinking of them as separate tools. Badges provide a gentle way to urge your users back into the app.
“Home Screen” Exposure – When your brand identity is on the home screen day after day it’s a constant reminder that you exist. Sure, it’s possible for someone to add an icon representing your web site to their home screen, but that’s relatively rare behavior.
Connectivity – Local storage has made it feasible to use a web app when the network is not available, but most web apps will require network access. Network coverage is improving, but anyone who uses a mobile device still regularly encounters dead zones. Network connectivity may still be essential even with a native app, but you have more and better options for ways to cache data that needs to be downloaded or uploaded and react when the network becomes available again.

The case for mobile-optimized sites

For the sake of discussion we assume “web” in this context means the kind of browsing experience you get on iOS and modern Android devices (as opposed to trying to build for the “browser” on, say, older Blackberry devices – a task we would not wish on our worst enemies).

Cross-Platform Support – As Android continues to gain market share it’s no longer enough to assume iOS is the only game in town for native apps. While iOS remains dominant in terms of actual humans actually using apps, if you want to reach a broad audience you need to target more than just iPhones and iPads, and the web is one of the best ways to do that.
Avoid App Stores – With web apps you don’t need approval from Apple to roll out a new version of your app, nor do you need to worry about whether people are bothering to upgrade to the latest version. When you deploy a new version you control when that happens and who sees it. This can reduce a lot of headaches in both timing and support.
Talent Leverage – Developing native mobile apps remains an art different from creating web applications. If your business requires both, that means figuring out ways to get your software built with two different teams. While mobile-specific web apps have some eccentricities that are different from “regular” web apps, the skills to build them are not appreciably different. That said, our experience is that most teams still need to expand resources when they get serious about mobile web experiences.
Total Cost of Ownership – In many cases a mobile web app can take advantage of existing code and process for your web app more easily than a native app. As you optimize for life with both a mobile and desktop web app you can build your development and business practices to minimize the distance between the two. For instance, a first version of a mobile web app might be as simple as conditionally loadings a stylesheet (if you’re lucky enough to have a well structured web app in the first place), which is certainly going to be cheaper than building out a satisfying native app. You risk getting what you pay for in this case, but at least you can try out a mobile experience much more easily on the web. That said, if you look at sophisticated mobile-specific web apps it’s likely they require similar resource levels as native apps to create and maintain.

Choosing whether to develop a native app or a mobile-optimized site is further complicated by the evolution of cross-platform tools such as PhoneGap, Titanium, and Trigger.io which allow the use of web technologies inside a native app wrapper. There is relative paucity of high-quality consumer apps built on these platforms, but the rising popularity of Android is forcing more difficult choices about which ecosystem(s) to target, so expect such tools to continue to mature and multiply.