Products Are Hard

You are here: Home / Archives for Product Strategy

Beyond Lean and Agile

By

Rose Powell of Australia’s StartupSmart interviews us on situating Agile and Lean in a holistic product practice.

Beyond lean and agile: Finding a more holistic approach to start-up creation

You need to step right out of it and remember no one’s goal is to use your product. They want to get something done. Does your product do that in the best, most efficient way possible?

Dig the conversation? Fancy being in Melbourne, Victoria on October 30? Join us for the Products Are Hard conference, Australian edition. 

G+ identity follies

By

Google wants real identities on G+. No pseudonyms. (After enduring enough protest, they relented for those with established pseudonymous public personae.) And yet, Google also gently but persistently harasses you to setup a G+ identity for every Google account you have. At the moment I have two personal Gmail accounts and three Google Apps work accounts. Google keeps insisting that I make a G+ profile for each one of those accounts, either by pestering me upon login or by disabling key features of applications like Hangouts for accounts without a G+ profile. I now have five G+ identities to manage. I can laboriously recreate my “circles” on each one and flesh each of them out, figure out some way to syndicate one of them to the other four, or simply ignore most of them, leaving them to molder as dusty ghost profiles. It’s hard to see how this is good for the health and vitality of G+ as a community or social network except to artificially juice the number of users.

The five pillars of product management

By

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

By

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.

Strategy and negative space

By

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

By

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. “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.
  6. 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).

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Un-human experience

By

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 than first focusing on optimizing the numbers flowing into an analytics system, we should instead ask what it is that actual humans would want.

Today I came across the most striking example I’ve seen yet of an experience decidedly not human:

Google News Gamification

Badges. For reading the news. Really. You can earn badges by reading certain kinds of news.

Who wants this?

This feature was created not by thinking about humans but rather by thinking about metrics and advertisers—gamification increases metrics such as number of page hits per session and frequency of sessions. Quantifying readers’ interests is beneficial to advertisers—if they know I’m interested in certain kinds of news, that is a valuable bit of targeting data (though they’d know that anyway, so the badges seem more about encouraging me to click more links). When people say that Google is an engineering-driven organization that doesn’t understand people, this is exactly what they are talking about.

Prediction: we will see increasing apathy and backlash to this kind of wanton use of game mechanics in domains that are neither competitive nor driven by external motivators.

Human experience

By

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 better. People don’t think of themselves as “users” and as practitioners we do ourselves a disservice to employ that dehumanizing term. In all other contexts the word “user” is not generally positive and certainly not evocative of the kind of intimate, day-to-day relationship we’d like our work to have with the people who interact with it.

This applies as well to the “Minimum Viable Product” – lately there have been a number of folks pointing out the term “viable” is too often ignored, resulting in the release of products that are simply not ready for human consumption. Perhaps if we all thought of it more as the Minimum Human Experience (hereafter referred to as MHX) we’d be less likely to release products that aren’t ready just to get them rushed out the door and instead focus our thinking on what the smallest coherent and valuable experience for a real person would be.

No Way To Start A Relationship

By

So, you’re almost ready to launch.  You set up a delightfully intriguing splash page that invites people to sign up for your preview release for forking over their email address. You rejoice at all the fabulous interest total strangers have in your product – the product you have poured blood, sweat, and tears into for weeks (or more). Then you start to wonder:

Wait, if people are this enthusiastic about my product they probably want to see it as soon as they can, and I really want to get as many people signed up as possible. I know! I’ll ask people to post to their Twitter/Facebook accounts and offer them a vague promise of being bumped up the queue of interested people.  Genius!

Then, you sit back and watch as your preview invite “goes viral” and pat yourself on the back for being so innovative (or for having someone else be innovative for you).

Stop. Just stop. Think about what just happened: before someone has even used your product you have taken the little bit of good will they seem to have and tried to bribe them to spam their friends. Sure, some of them will do it. Your numbers will look great, showing viral lift before you even launch. But those numbers don’t speak to the people you turned off. Those numbers don’t speak to the overall impression people came away with after signing up for your preview.

Being data-driven is great, but not if it comes at the expense of keeping the big picture in mind: you want to build a trusted relationship with your early adopters. They will, most likely, be the difference between you succeeding and you being a flash in the pan. Ask yourself, which people are most likely to actually spam their friends with a link to your invite just to get higher in the queue? Do you suppose there’s a high correlation between those willing to do that and those who are likely influential with their friends?

Relationships are more important than numbers, especially in the early days. You’d rather have a few hundred rabid fans ready to give a an enthusiastic, trusted opinion of your product than a few thousand social media over-posters randomly spewing your link into the ether. If someone is willing to give you their email address just because your product seems intriguing how else could you use that moment to start a strong relationship?

Get in touch

415.683.6936
@productsarehard