Mark Hendrickson

Kanban

Tue, 11 Dec 12 18:32:17 +0000

One of the most important aspects of product design and management is prioritization. There are only so many resources at a company's disposal at any given time that product efforts must be prioritized vigilantly lest a team end up spending considerable time producing sub-optimal or worse, misguided, work. This is especially true at a startup where resources are extremely constrained and product efforts can either suffer or benefit greatly from acute path dependency.

I've found that the simplest yet most effective tool to prioritize product developments is kanban, or at least my interpretation of it. A well-organized kanban board can help a team visualize what product ideas currently are or are not getting attention, by what team members, and why. It encourages a "lean" mentality by putting ideas into a sequence of design, development and validation only when there is current capacity to do so. And yet it also provides a staging area for longer-standing ideas that await their turn for production.

You can use digital software to create a kanban, such as Trello, but I actually prefer old-fashioned notecards, tape and markers. To create one, you simply need these materials and a decent amount of wall space. You'll be writing down product ideas onto the cards and then taping them up on the wall under predefined columns and sections depending on where they belong. A big advantage of doing this on the wall is that you can very readily use the board during meetings to communicate product direction without having everyone burrow into their laptops. A wall-based kanban system is also more customizable on-the-fly.

Product ideas, corresponding to notecards that primarily display their label (e.g. "Daily Digest Email"), start off in the left-most "Icebox" column and move rightward through "Design", "Develop" and "Validate" columns as they proceed along the production process. Ideas start in the icebox because all ideas deserve justification before they get any significant attention from the team, and as the name suggests, the icebox is where ideas stay frozen (i.e. no one is working on them). Whenever you or anyone else on the team thinks of a clever new product idea, it should be put up on the board in the icebox because then it can be considered for production.

I like to divide the icebox into sub-columns for the organization of ideas by their primary purposes. A primary purpose should be determined for every idea, even if that idea serves several purposes, because otherwise it's hard to justify its enactment and later validate its success. You may find that the purposes you outline on the board vary from product to product, but for many products, you can boil them down to mainly user/customer "Acquisition", "Activation", and "Engagement". For example, the daily digest email example above should probably go under "Engagement" because the main hypothesis behind such an email would be that it could increase the engagement frequency and long-term retention of users. A different idea, such as "Send Invitations Page", could go under "Acquisition" because it's intended to help with viral distribution.

You can order product ideas under each column based on your current sense of their appropriate prioritization, but any such prioritization should be tentative since ideas ought to be pulled from the icebox as the result of iterative assessments about what's worth resources (perhaps as frequently as on a weekly or biweekly basis). It's also ideal to identify what measurable impact on the product will indicate success for an idea before it's taken out of the icebox and put into production (i.e. you could hypothesize that long-term user retention will increase 5% with the introduction of daily digest emails). Kanban is intended to help you prioritize by product ideas by potential impact, but this shouldn't be interpreted as creating a "waterfall" situation where ideas are prioritized concretely and deeply into the icebox. Otherwise, you'll find that you aren't properly making incremental product decisions based on the most up-to-date information at your disposal, and you could get yourself locked into unproductive product directions for months or more at a time.

Once it's determined that an idea should go into production – because it contains the greatest potential for addressing the most-pressing business needs (such as user engagement or acquisition) – its card gets moved from the icebox and into the "Design" column. This column in divided into two rows: "In Progress" on the top and "Done" below. An idea first goes into the "In Progress" row, which indicates that designers have begun actively working on its design. Once the designers have finished all anticipated design work for the idea, it moves to "Done", which is where it ought to stay, however briefly as possible, before moving into the "Develop" column.

Similarly to the "Design" column, the "Develop" column indicates when ideas are getting attention from developers, or engineers. The "Develop" column has two rows: "In Tracker" on top, and "In Progress" on bottom. Because I've used kanban to visualize product prioritization in conjunction with Pivotal Tracker for engineering prioritization, the "In Tracker" row indicates when a given product idea has been picked up by the engineering team and added to their own pivotal tracker projects, which allows them to break it down into specific engineering tasks. The presence of an idea in the "In Tracker" section of "Develop" rather than the "Done" section of "Design" indicates that its aims and designs have been explained and delivered to developers, and the idea is therefore in their court to proceed with execution. When they do start working on an idea (which should be quickly in a well-regulated kanban system), it moves to "In Progress" until complete.

Since kanban is best used with continuous deployment, there is no "Done" row for the "Develop" column; cards simply move to the "Validate" column, which indicates that their ideas have gotten deployed to actual users and are awaiting validation. The "Validate" column can be split into two rows if you have both a beta and live environment (i.e. when ideas get pushed into beta testing, they should go under a "Beta" row, and when they go fully live, a "Live" row). Notice that cards aren't simply taken off the board once they've been deployed, since the validation column is intended to remind a team that they need to follow up on whether the idea they built actually had its intended effect.

Deployed ideas stay in the validation column until it's determined that they succeeded according to plan, at which point they're removed from the board. But if they (perhaps more likely) failed or fell short, they are moved backwards through the board to whatever stage is deemed necessary ("Icebox" if the team gives up on the idea for now, "Design" if its failure is deemed a design shortcoming, or "Develop" if it's found buggy or incorrectly implemented). Because it's easy to come up with low standards for validating ideas post-production, you'd do best to use the exact hypothesis you stated originally for an idea when determining whether it validated successfully, even if that means leaving a card in the "Validate" column for an extended period of time to gauge its effect.

When you begin using a kanban board to track the execution of product ideas, you'll notice the bottlenecks in your overall production process. Cards may begin to pile up in the design, develop or validate columns, indicating that you need more resources in those areas if you want to produce so much at a given time. And if you can't add the required resources, you'll know you need to scale back how much you bite off or break down ideas into smaller chunks, with the goal of keeping each of your resources at full (but no greater) capacity.

If you begin using such a kanban board – hopefully to discuss product direction at regularly scheduled meetings – you'll inevitably find ways to customize it according to the needs of your particular team and product. And these customizations should be made with an eye towards augmenting the board's ability to prioritize the highest-impact product ideas and speed up the process by which they go from design to validation. If you manage to do this, you'll gain peace of mind that you're making the best product choices possible and following through on them effectively.

Success projection for startups

Wed, 05 Dec 12 03:31:06 +0000

Startups often get so consumed by their day-to-day challenges that they do a poor job actually projecting their longer-term success or lack thereof. As a result, many toil without knowing whether they're truly living up to the expectations they've set for themselves or not.

Even though there is a lot of uncertainty surrounding early-stage companies, they'd do well to build working projection models that give them a sense of whether they're on a road to success or growing too slowly per business metrics that matter to them most.

All startup stakeholders (founders, employees, investors, etc) ultimately gauge their long-term success by the company's anticipated valuation at the future point of time when they decide to liquidate their equity holdings, perhaps several years or more after they begin working on it. Therefore, any projection of success should place this valuation as its end goal and work backwards from there to derive the more immediate factors that go into achieving that success and whether those factors are on the right course.

A company's valuation is derived (at least theoretically in an efficient market) by the total amount of profit it will accumulate forever into the future, discounted to a present value. So, the first derivation from valuation is long-term profit, and since this profit consists of the company's expected revenues and costs, those come next.

Costs can be derived by projecting headcount and other operational expenditures, perhaps by studying public information about other companies that have developed in the same way as you expect your company to do so, providing rough guidance as to how your particular and total costs may pan out over the years.

Revenue can be projected through comparables as well, especially if you anticipate deploying a business model similar to that of a public company (e.g. you could study companies that make most of their money from display ads if that's what you also intend to do). However, you will likely learn the most from them about what kinds of per-unit rates they get from various monetization schemes (such as subscriptions, e-commerce fees, and advertising CPMs), leaving it to you to determine what kind of product usage volume you anticipate mapping against such expected rates.

If you are, like many consumer startups, intending to generate revenue from advertising, then the model's key questions are consequently: 1) how many active users do you expect to attain by a given date in the future, and 2) how active will they be per day, week, month or year. And this is because you'll need to estimate the size of an active audience that'll be at your disposal for advertisers. You may come up with innovative ways to increase ad rates, but your future revenue will be mainly tied to how large or small that audience becomes.

With this being the case, you need to focus on how quickly you are accumulating active users and increasing their engagement, and this is where the model starts to get concrete for even the newest of startups. The number of active users for a product at any given point, now and into the future, is determined primarily by its user acquisition rate (how many people are signing up or otherwise first engaging with a product per a given unit of time), its activation rate (what percentage of those people reach a point of appreciation for the product), and its retention rate (what percentage of those who activate continue to use the product repeatedly).

Each of these factors (as well as others that correspond to non-advertising-based business models) is unique to a given product, and eventually you'll need to project them all if you want to complete the model. However, even if you're at a beta stage with only 50 testers, you can start projecting them one-by-one, making assumptions about the rest. You won't have a lot of statistical significance with such a small user base, and it's probable that your key metrics will change as you address a larger market. But it'll at least give you a baseline from which you can judge movements towards or away from your ultimate definition of success (i.e. how valuable you want the company to become and how quickly). And it'll keep you honest about whether you truly have enough data to establish knowledge about the business's momentum, and if you do, whether that data reinforce or contradict your more subjective intuitions about how well the startup is doing.

Three types of design

Thu, 06 Dec 12 18:51:00 +0000

People tend to use the word "design" very loosely when talking about product, but it's actually quite important to distinguish between the types of design (and their respective designers) when seeking to understand what someone means by the term in any given context, as well as how they apply to the overall product development process.

I tend to divide design into three main types: product, interface, and visual.

Product Design

The goal of product design is to generate and prioritize functionality that could potentially deliver value to users in correspondence with the product's stated purpose, or to modify that stated purpose when no such functionality has sufficient potential.

A product designer spends their time mainly thinking about user flows and experiences, which is to say, how users ought to encounter the product at various points in their lifecycles, what they are enabled to do upon those encounters, and how that enablement provides users with additional value.

Such a design involves the least amount of illustration of the three types, but those in the form of low-resolution diagrams, flow charts, and even rough interfaces can help get the point across about how the functionality should work. Often the output of product design consists of verbal materials, such as outlines and essays that convey how the functionality will suit users' needs and psychological profiles.

A good product designer is aware that prioritization is key to their work because there isn't enough time or resources for all promising ideas and the ones with the most promise must be tackled first. And the product designer must continually map this product prioritization to the company's most pressing business objectives.

Interface Design

The goal of interface design is to translate the conceptual functionality conveyed by the product designer and articulate how the user actually experiences and manages to understand that functionality in the product, on a step-by-step basis.

If the product is a website, the focus is on arranging and defining various elements on each page that provides the user with information and input. If the product is a mobile application, then the medium is screen-by-screen, and if physical, its available materials.

The interface designer is most responsible for making the product as intuitively usable as possible so that the highest percentage of users derive the value promised by it. A good interface designer understands the constraints and opportunities afforded by their medium and plays the very empathetic role of envisioning and studying how people of all targeted backgrounds will learn (or fail to learn) how to use the product. And they're intent on ensuring that the interface elements come together in a cohesive whole that makes sense to users architecturally, delivering those elements as wireframes or other medium-resolution materials to the visual designer.

Visual Design

The goal of visual design is to ensure that the product conveys a sense of quality and elicits the proper emotional response from its users.

Visual design is the most aesthetic and subjective design type, but it's also the most immediately recognizable one. While visual designers take their cues from product and interface designers, they are responsible for crafting and delivering an ethos for the product. They spend most of their time making interface elements both attractive and appropriately toned so as to reinforce the purpose and value of the product for users, and a good visual designer knows how to make a product pleasurable without making assets that are overly conspicuous.

A visual designer spends the most time on detail, since they sit closest to the user's actual experience. And they deliver high-resolution images, animations or other user-ready elements that can be incorporated directly into the product.

Interrelation of types

These types can be treated as a hierarchy, in the sense that product design mainly informs interface design, and interface design mainly informs visual design. And as such, it's more important to execute successfully on the product design front than the other two, because decisions (both good and bad) made in that tier will cascade to the others. And it's hard, if not impossible, to make up for shortcomings in product design with amazing interface or visual design (or, likewise, to make up for poor interface design with a compelling visual design).

However, it's not desirable nor even theoretically possible to focus exclusively on product design without investing in the other two types. There's no way to actually manifest your product, let alone in a way that consumers find appealing, without spending a decent amount of time actually thinking through its interface and visual considerations and generating outputs from them. In an extreme yet feasible scenario, you could have barebones interface and visual design paired with solid product design and you might eek out traction in a marketplace, but you'll be making life a lot more difficult for yourself.

The practical question that startups often face, then, is how much attention to give each of these types of design, especially when their general hierarchy is recognized. Does interface design get 50% of the attention as product design, and does visual get 25% of that? Or do they all get roughly equal treatment, or some other division? The answer basically boils down to how much usability friction users can be expected to tolerate (on the interface front) and how central the notions of quality and emotion are to the product's value proposition (on the visual front) at any given release point.

If you are distributing a product (perhaps a business tool) to people who will likely find value from even a poor user interface and don't care much about how their tools look and feel, then you probably don't have to spend as much time on interface and visuals. But if your product (perhaps a game) needs to sway inexperienced and skeptical new users that it'll dependably provide them with emotional satisfaction, then you may want to make a thorough investment in all three design types. The consideration, therefore, is ultimately a marketing one.

The Post-MVP Fork in the Road

Wed, 28 Nov 12 03:02:26 +0000

A lot of startups rightly aim to release a minimum viable product (MVP) as their first initiative. The goal of an MVP helps a team rally around a concrete product design that they can get out the door in a limited amount of time. And it's every startup's hope that once the MVP is released, early adopters will flock to it eagerly and tell their more mainstream friends by the millions.

When most MVPs get released, however, this dream doesn't exactly pan out. Instead of experiencing healthy growth and engagement, the MVP gets tepid interest from the market. It's neither an entire flop, since there are people who adopt it and do seem to like it quite a bit. Nor is it a clear success, since these people number in the hundreds or thousands, and their numbers don't appear to grow very quickly.

At this point in the startup's lifecycle, it faces a fork in the road wherein it can decide just what to do about its MVP. Most startups think to themselves: "OK, it looks like we have the beginning of something interesting even if it's not an instant hit. If we just iterate on the core product and make it incrementally better, we'll hopefully get it to the point where its value to the ordinary user reaches an inflection point and our active users will take off."

This is a very dangerous mindset to adopt post-MVP, because you're inherently conceding that your minimum viable product was, well, unviable. But you're also skirting that reality in practice. If the MVP contained the most important kernel of the experience you were hoping to provide users and that kernel itself didn't get most people who tried it excited (judged primarily by your retention rate), then your fundamental thesis was wrong. Adding extra features, design refinements, and performance enhancements on top of the MVP is not going to change the main lesson you've already learnt, which is that the core concept you've released does not resonate with the market you had in mind.

The other path, which far fewer startups take upon releasing their MVP to an unenthusiastic market, is to stop and honestly assess what they've already attempted with it. Instead of going head-first into a mode of iteration, startups on this path critique their MVP's core experience and develop hypotheses as to why it wasn't found compelling enough by the market that tried it. These startups either attempt the same MVP with a significantly different market, having decided that the one they initially approached didn't have matching needs. Or they stick to the same market and revamp the fundamentals of their product, essentially going back to the drawing board.

Inertia is the reason you don't see many startups make this hard decision to question the essence of their market or product. And this inertia is often created by a whole host of factors, such as founder vision, investor and employee buy-in, and press exposure. When you're running product for a startup, it's much easier to stay headstrong about your initial concept and ignore clear market feedback, since one perceives it as too difficult to reorient the entire game plan and messaging for the product*. It's also relatively easy to rationalize that the market simply needs more time to come around, or that just a couple more features will make it "click" with people, especially if you have money in the bank and supportive advisors who don't want to dampen your enthusiasm for it.

But the bravest and most critical thing that product managers at startups can and must do is treat their products as the experiments they are, maintaining a critical and detached eye for what they're building, at least until those products reach a pace of undeniable growth and engagement that makes it clear a market clamors for them.

* I was certainly guilty of this with Plancast.

Does your product provide instant gratification?

Thu, 06 Dec 12 00:03:52 +0000

Over the past year, and mostly as a result of my Plancast post-mortem, I've spoken with dozens of entrepreneurs who are working on events-related internet products.

I had a call with another such entrepreneur today who has actually built and released a considerably robust offering, at least from a feature standpoint. The service makes it possible to interact with event data in myriad ways, from personal sharing of plans among close friends to impersonal broadcasting of events to a wide audience. It consists of not only a website but a mobile client and calendar client synchronization to boot.

The problem, however, was that any given person who encounters the service will be at a loss as to why they should use it, and this was the case for two reasons:

1. It's not clear which of the features is primary. The product doesn't sell itself as useful for any particular use case; rather, it leaves it up to the user to figure a main one out for themselves, which they're unlikely to do unless they already have a clear, burning need.
2. No one feature in particular provides instant gratification. Even if the new user does manage to determine their use case, none of the ones available provides value immediately. They all demand that the user invest considerable time, energy and open-mindedness before they can likely get any substantial value back.

These are problems I see often with events services because they can take many different (and often nuanced) forms. For example, they can be about delivering invitations, discovering social opportunities, interacting real-time, networking with other attendees, and more. As a result, product designers often try to stuff several of these forms into one product.

Event services also wrangle with the issue of delayed gratification, because if the event data (likely) refer to something in the future, you won't fully appreciate the service until you actually attend the event. It's hard to accelerate the value you get, especially since anticipating events also imposes a good deal of psychological overhead, which isn't pleasurable.

However, these are problems from which I see many other types of products suffer as well. If you are building something and you can't pinpoint the point in time when many, if not most, new users can reliably achieve gratification upon their first usage (and by that I mean their first time visiting or registering for your website or downloading your app), then you probably have a structural problem with your value proposition. Especially in this day and age, when people mostly treat new internet services as nice-to-haves rather than needs, your product's value needs to be singular and immediately available or you probably won't get a second look.

A Post-Mortem for Plancast

Sun, 15 Jul 12 18:00:19 +0000

This post was originally published on TechCrunch in January 2012.

Nearly three years ago, I left my position at TechCrunch to start my own Internet business, with the idea of creating a web application that’d help people get together in real-life rather than simply helping them connect online as most social networking applications had done.

Plancast was the service conceived a few months later from that basic inclination. Its approach was to provide a really easy way for people to take whatever interesting plans they had in their calendars and share them openly with friends, with the rationale that greater social transparency for this particular type of personal information would facilitate serendipitous get-togethers and enable a greater awareness of relevant events. Personally, I figured that knowing more about the events my friends and peers were attending would lead to a more fulfilling social and professional life because I could join them or at least learn about how they spent their time around town.

Along the way my team built a minimum viable product, launched from obscurity here on TechCrunch, raised a seed round of funding from local venture capitalists and angel investors, and worked like mad to translate our initial success into long-term growth, engagement and monetization.

Alas, our efforts began to stall after several months post-launch, and we were never able to scale beyond a small early adopter community and into critical, mainstream usage. While the initial launch and traction proved extremely exciting, it misled us into believing there was a larger market ready to adopt our product. Over the subsequent year and a half, we struggled to refine the product’s purpose and bolster its central value proposition with better functionality and design, but we were ultimately unable to make it work (with user registration growth and engagement being our two main high-level metrics).

This post-mortem is an attempt to describe the fundamental flaws in our product model and, in particular, the difficulties presented by events as a content type. It’s my hope that other product designers can learn a thing or two from our experience, especially if they are designing services that rely on user-generated content. The challenges I describe here apply directly to events, but they can be used collectively as a case study to advance one’s thinking about other content types as well, since all types demand serious analysis along these lines should one seek to design a network that facilitates their exchange.

Sharing Frequency

Social networks (by my general definition and among which I count Plancast) are essentially systems for distributing content among people who care about each other, and the frequency at which its users can share that content on a particular network is critical to how much value it’ll provide them on an ongoing basis.

Unlike other, more frequent content types such as status updates and photos (which can be shared numerous times per day), plans are suitable for only occasional sharing. Most people simply don’t go to that many events, and of those they do attend, many are not anticipated with a high degree of certainty. As a result, users don’t tend to develop a strong daily or weekly habit of contributing content. And the content that does accrue through spontaneous submissions and aggregation from other services is too small to provide most users with a repeatedly compelling experience discovering events.

I run the service, and even I currently have only five upcoming plans listed on my profile, with a total of 500 plans shared over the last couple of years, in contrast to almost 2,800 tweets on Twitter over the same period of time. People often tell me “I like Plancast, but I never have any plans to share”. With social networks, this is sometimes a case of self-awareness (such as when people say they don’t know what to tweet), but often they’re simply telling the truth; many Plancast users don’t have any interesting plans on their calendars.

Consumption Frequency

People also don’t proactively seek out events to attend as you might suppose. I’ve gotten into the habit of thinking about people as divided into two camps: those who have lots of free time and those who don’t.

Those who do are often proactive about filling it, in part by seeking out interesting events to attend in advance. They are generally more inquisitive about social opportunities, and they will take concrete steps to discover new opportunities and evaluate them.

Those who don’t have much free time often desire to conserve it, so rather than seeking out or welcoming additional opportunities, they view them as mentally taxing impositions on a limited resource. For them, planning is a higher-risk endeavor, and usually they’d rather not plan anything at all, since if they’re busy, they likely have a preference to keep their free time just that – free.

It’s hard to generalize by saying most people are in one camp or the other, but suffice to say, there are many people in the latter. And for them, it’s hard to get them excited about a service that will give them more options on how to use their time.

Tendency to Procrastinate

Even putting this bifurcation aside, most people resist making advanced commitments before they absolutely need to make them. People fear missing out on worthwhile events but don’t actually like to take the deliberate initiative to avoid such missed chances, which requires planning.

This can be attributed primarily to people’s desire to keep their options open in case other conflicting opportunities emerge as the date and time of an event approaches. If they can afford to wait and see, they will. Therefore, their commitment will be secured and shared in advance only when they’re particularly confident they’ll attend an event, if they need to reserve a spot before it fills up, or if there’s some other similar prerogative.

Incentives to Share

Returning to the topic of sharing plans, it’s not only a matter of having interesting plans to share but being compelled to actually share them. And unfortunately, people don’t submit information to social networks because they love data set integrity or altruistically believe in giving as much as possible. They do it because the act of contribution selfishly results in something for them in return.

Most social networks feed primarily on vanity, in that they allow people to share and tailor online content that makes them look good. They can help people communicate to others that they’ve attended impressive schools, built amazing careers, attended cool parties, dated attractive people, thought deep thoughts, or reared cute kids. The top-level goal for most people is to convince others they are the individuals they want to be, whether that includes being happy, attractive, smart, fun or anything else.

This vanity compels folks to share content about themselves (or things they’ve encountered) most strongly when there’s an audience ready and able to generate validating feedback. When you post a clever photo on Instagram, you’re telling the world “I’m creative!” and sharing evidence to boot. Those who follow you validate that expression by liking the photo and commenting positively about it. The psychological rush of first posting the photo and then receiving positive feedback drives you to post more photos in the hope of subsequent highs.

Sharing plans, unfortunately, doesn’t present the same opportunity to show off and incur the same subsequent happy feelings. Some plans are suitable for widespread consumption and can make a person look good, such as attending an awesome concert or savvy conference. But, frustratingly, the vainest events are exclusive and not appropriate for sharing with others, especially in detail.

The feedback mechanisms aren’t nearly as potent either, since coming up with a worthy comment for an event is harder than commenting on a photo, and “liking” a plan is confusing when there’s also an option to join. The positive feedback of having friends join is itself unlikely since those friends have considerations to make before they can commit, and they’ll tend to defer that commitment for practical purposes, per above.

Additionally, if a user wants to show off the fact they’re at a cool event, there is little additional benefit to doing so before the event rather than simply tweeting or posting photos about it while at the event. An important exception is to be made for professionals who style themselves as influencers and want to be instrumental parts of how their peers discover events. This exception has indeed been responsible for much of our attendee-contributed event data among an early-adopter community of technology professionals.

Selectivity & Privacy Concerns

Vanity, of course, is not the only possible incentive for users to share their plans. There’s also utility to getting others to join you for an event you’ll be attending, but this turns out to be a weak incentive for broadcasting since most people prefer to be rather picky about who they solicit to join them for real-life encounters.

While event promoters have a financial interest in attracting attendees far and wide, the attendees themselves mainly turn to their closer circle of friends and reach out to them individually. You don’t see a lot of longer-tail plans in particular (such as nights out on the town and trips) because people are both wary of party crashers and usually uninterested in sourcing participants from a wide network.

The Importance of an Invitation

On the flip-side of this reluctance to share plans far and wide is the psychological need for people to get personally invited to events.

Plancast and other social event sharing applications are rooted in an idealistic notion that people would feel confident inviting themselves to their friends’ events if only they knew about them. But the informational need here is not only one of event details (such as what’s going to happen, when, where and with whom). People often also need to know through a personal invitation that at least one friend wants them to join.

When you have a service that helps spread personal event information but doesn’t concurrently satisfy that need, you have a situation where many people feel awkwardly aware of events to which they don’t feel welcome. As a result, the most engaging events on Plancast are those that are open in principle and don’t solicit attendees primarily through invitations, such as conferences and concerts, where the attendance of one’s friends and peers is a much less important consideration for their own.

Content Lifespan

Getting content into a social network is not enough to ensure its adequate value; there’s also an importance of preserving that content’s value over time, especially if it just trickles in.

Unfortunately, plans don’t have a long shelf life. Before an event transpires, a user’s plan for it provides social value by notifying others of the opportunity. But afterwards, its value to the network drops precipitously to virtually nothing. And since most users don’t have enough confidence to share most plans more than one or two weeks in advance, plans are typically rendered useless after that length of time.

Contrast this expiration tendency with more “evergreen” content types, such as profiles and photos. Other people can get value out of your Facebook profile for years after you set it up, and the photos you posted in college appear to have even increased in value. Nostalgia doesn’t even have to play a part; people’s hearts will melt upon viewing this puppy on Pinterest, Tumblr, and other visually-heavy content networks for a long time to come. But how much do you care that I attended a tech meetup in New York last October, even if you’re my friend?

Geographic Limitations

Geographic specificity is another inherent limitation to a plan’s value. Unlike virtually all other content types (with the exception of check-ins), plans provide most of their value to others when those users live or can travel near enough to join.

I may share plans for a ton of great events in San Francisco, but few to none of my friends who live outside of the Bay Area are going to care. In fact, they’ll find it annoying to witness something they’ll miss out on. Sure, they might appreciate simply knowing what I’m up to, but the value to that kind of surveillance is rather modest all by itself.

This is especially problematic when trying to expand the service into new locations. New users will have a hard time finding enough local friends who are either on the service and sharing their plans already, or those who are willing to join them on a new service upon invitation. People who encounter the service from non-urban locations have the hardest time, since there aren’t many events going on in their area in general, let alone posted to Plancast. Trying to view all events simply listed within their location or categories of interest yields little for them to enjoy.

Looking Forward

Despite all of these challenges, I still believe someone will eventually figure out how to make and market a viable service that fulfills our aims, namely to help people share and discover events more socially. There’s simply too much unearthed value to knowing about much of what our friends plan to do to leave information about it so restricted to personal calendars and individuals’ heads.

Another startup may come along that develops insight into an angle of attack we missed. Or, perhaps more likely, an established company with an existing event or calendaring product will progressively provide users with a greater ability to share their personal information contained within. On the calendaring side, Google is possibly the best-situated with Google Calendar and Google+, which together could make for a very seamless event sharing experience (one of the things we considered seriously for Plancast was deep personal calendar integration, but a sufficient platform for it simply wasn’t available). On the events side, companies like Eventbrite, Meetup and Facebook have services that are primarily compelling for event organizers but already contain useful data sets that could be leveraged to create their own social event discovery and sharing experiences for attendees.

Plancast managed to attract a niche audience of early adopters who found it to be among the most efficient ways to share and hear about events (thanks, users! you know who you are). Over 100,000 have registered and over 230,000 people visit each month, not to mention enjoy the event digests we send out by email each day. For that reason alone, and despite its growth challenges, we’re going to keep it up and running for as long as possible and are hopeful we’ll find it a home that can turn it into something bigger. It’s my expectation that one day mainstream society will take for granted the type of interpersonal sharing it currently enables for just this small community, and I look forward to seeing how technological advancements overcome the aforementioned challenges to get us there.

Share frequency

Fri, 12 Aug 11 21:35:05 +0000

When designing a social network that depends on users to contribute content from which they'll collectively derive value, one must consider certain qualities of its supported content types to determine whether those types can provide enough ongoing value to keep users engaged.

Among these important qualities is the frequency with which people are compelled to create and share a given type of content. People are interested in sharing some types on a seemingly continual basis, spacing out contributions mere hours, minutes or even seconds apart. Conversely, there are types that make sense to share only occasionally when unique opportunities or needs arise.

While the suitable frequency of each type varies between individuals, generalizations can be made for evaluation and comparison purposes. For example, status updates, which a given person might find him or herself compelled to produce several times per day, lend themselves to a greater frequency than blog posts, which the same person might publish only every few weeks.

The general frequency of a particular content type results from numerous factors that affect the costs and benefits of sharing it. All else being equal, types that are easy to produce, such as check-ins or one-off photos, enjoy a greater frequency than those that take more time and consideration, such as restaurant reviews or entire photo albums. Types that return more value to the producer, such a thoughtful answer to a question that earns social acclaim, also enjoy greater frequency than less beneficial types that require the same investment.

It also seems clear that people, due to their impatience, have a greater cost elasticity than benefit elasticity, in that a little less effort makes a bigger positive impact on frequency than a little more benefit. This asymmetry might help to explain why we've seen smaller, bite-sized types of sharing emerge, whereas we haven't seen as many new services that target types with higher costs yet higher yields.

It's also possible that with current feedback mechanisms (which provide superficial doses of social validation rather than more impactful, long-standing personal gains), there are simply more apparent opportunities to reduce costs than increase benefits, even if that results in a downward movement of publisher value (and likely consumer value) per share.

Every type of content has its own set of reasons for why it presents people with higher or lower costs and benefits, and a study of each is necessary to understand their resulting frequencies. When choosing one or more types for a new service, it's important to conduct this study to determine whether they'd yield a high enough frequency to engage users on a continual basis.

Higher frequency generally leads to greater engagement if only because it enables the production of more content within a given period of time and, after all, content is the lifeblood of any social network and needs to accrue. If the value of content is also dependent at least partly on its recency (as is the case with virtually all types, to varying degrees), frequency is even more important because there must be enough new content available at any given time that users decide to engage with the service. The depreciation of existing content essentially needs to be counteracted by fresh content at a sufficient enough rate.

The need for a relatively high sharing frequency is particularly acute due to an increasing number of services vying for consumers time and attention. Each additional service drives up the minimum value users demand from the next, either as producers or consumers of content. An important question for social network designers, then, is what are the types of content that will provide enough net publishing value that they elicit frequent contributions from their target demographics, especially as their opportunity costs rise.

Homesteading on the indie web

Sat, 30 Jul 11 00:03:21 +0000

I had the pleasure of attending IndieWebCamp in Portland last month, a BarCamp-style conference where techies get together to brainstorm ideas about how they can help people own and control their online identities.

The so-called indie web movement, a spiritual cousin to the open source and standards movements, is rooted in a desire for digital freedom, primarily from monopolies that threaten to restrict and violate the common Internet user's online existence. It calls for practical means to protect this existence by preventing or disrupting the control that any one company has over a person's online identity, either from a functionality or data point of view.

It's a thought-provoking movement for a number of reasons, not least because it finds itself screaming into the wind, so to speak. Most Internet users, with the proliferation of social networks, increasingly place their digital lives in the hands of proprietary services run by mostly private — and always self-interested — companies. These users don't own the identity and content they publish to these services in a way that insulates them from their vague terms of service and the application thereof. Nor can they continue to enjoy those services (at least in the same manner) if the companies shut them down, redesign them undesirably or fail to improve them. Yet, only a small minority of users actively worry about these problems and usually only once they've been stung by account deactivation, incessant downtime, censorship, privacy leaks, or critical design shortcomings.

There's a moral tone to the indie web movement, not just an insistence that users ought to control their online identities for the practical purpose of avoiding conflicts with their service providers. Proponents argue that the Internet needs to maintain its decentralized nature and resist consolidations of power lest technological progress gets stymied, data gets lost, hoarded or corrupted, and users get disenfranchised en masse. There's a tension here, since private companies that treat their users as virtual sharecroppers are clearly responsible for much of the progress occurring on the web today, and their services are making it dramatically easier for everyone, including the technically illiterate, to participate online.

There were two particular challenges to the indie web movement that struck me while attending the conference. The first had to do with identifying the relevant and recognizable needs of the average Internet user to obtain better control over their online identity. Indie web proponents lodge a disparate number of valid complaints against proprietary services, each with its own merit but none that would be recognized by mainstream audiences as a massive, immediate problem on its own.

Tantek Çelik, the conference's lead organizer and my gracious host, cited the famous downtime of services like Twitter and Tumblr as reason for decentralization, as well as the tendency of acquired services to get shut down. Others cited the desire to more easily export and manage the content they post to services so it can be used on their personal computers and published elsewhere on the web. For others still, it was primarily an issue of personalization and the ability to interact with numerous online services and their respective functionality with more flexibility and fluidity.

All of these are pain points that are best articulated by technologists who take the time to understand them but are surely felt by "normals" as well. They don't, however, seem top of mind enough to compel millions of ordinary Internet users to take concrete steps to address them, at least with today's solutions. Downtime is frustrating but most people learn to work around it; shuttered services disappoint loyal users but most likely faced their demise due to popular disinterest; and most people don't know what else they want out of the services they use, at least substantially enough to seek alternative solutions.

This complacency poses a critical motivational problem for the primary decentralization scenario proposed by those in the indie web movement, wherein users (both early- and late-adopter alike) take the initiative to host their identity and personal content independently of any proprietary service. The idea here is that everyone should register their own second-level domain and put up a personal website of some sort, just as I've registered markmhendrickson.com and centralized my online identity there. This site could be a simple, static presence or advanced enough to exchange information with proprietary services so that interactions can take place with friends or followers. Theoretically, these proprietary services could get cut out entirely over time, and independent personal websites could begin communicating with each other directly, effectively mapping social networking relationships onto the Internet in a distributed, peer-to-peer fashion.

In addition to the marketing challenge of compelling individuals to establish these independent sites, there's the technical challenge of bringing this distributed system to life and making it possible for normal people to get involved. The technical challenge can be divided on one side into the infrastructural issues of decentralizing the real-time communications that currently take place within centralized services (such as forging social relationships, posting content to streams, and interacting with that content). On the other side, there are the technical issues of setting each user up within the decentralized system and making sure they have the tools needed to participate without getting tied to any single provider.

Each IndieWebCamp attendee spent the second day of the conference working on a self-chosen project that would aid the movement. I took it upon myself to devise a tool that would perhaps solve the second half of this technical challenge while also communicating to mainstream users why they ought to set up their own domains. My project was primarily user-centric, since it deferred many of decentralization's intricate engineering decisions and instead focused on motivating users to overcome their default complacency and break ground on their own online homestead.

I established several main requirements for this tool:

It had to simplify for users the process of registering a domain name and a basic web host, both of which had to be treated as commodities and substitutable at any time. While it's not possible or feasible for users to literally own their domain and hosting, the next best thing is to minimize the differentiation power of these services by abstracting them away.
It had to automate the process of setting up an initial website, or homestead, on the newly registered domain and host, as well as to automate the processes of updating or extending it later on. While the software for the website had to be fully hosted by the user and open-sourced for maximum control, it could be assisted by the tool on an ongoing basis through code and data pushes.
The user couldn't be expected to use FTP, a command line interface, a file system, or any other technologies beyond the browser because doing so would severely limit its accessibility. User interactions had to be limited to filling out web forms and clicking on things.
The financial and time burden of using the tool to both set up and maintain a homestead needed to be minimized as much as possible.
Users couldn't be required to reenter their personal information or manually upload content they've already shared elsewhere.

The tool's initial user experience is outlined by the wireframe above. The marketing appeals directly to a person's need for control, since that's ultimately what users are expected to obtain in a decentralized system, it likely resonates with an underlying fear that their current online identity may be in disarray, and it's a vague enough proposition to allow many solution details.

The page then addresses four of the most identifiable needs under the tent of controlling one's online identity. Obtaining a personal URL allows a user to more easily point people to their information online; ranking well-curated personal information highly on Google allows a user to control what people find out about them when searching their name; listing all of a user's social networking profiles in one place brings order to identity fragmentation; and backing up a user's online content from numerous sources provides peace of mind. The area at the bottom that lists other people's websites is meant to provide social validation for these propositions.

To get started, the user needs to enter just their desired URL, an email address and a password (with the desired URL checked against a domain registrar's API, assuming one exists). Requests for other values, such as the user's name, are omitted since they can be gathered from the user later on. The goal here is to have them engage with the setup process as painlessly as possible.

Upon entering this basic information, the user is prompted to connect their new homestead to any number of their online services. A link to each of these services, once connected, will show up on the user's homestead. Content posted to them can also be pulled, either once or continually, for redisplay or simply backup on the user's homestead, depending on what kind of service it is.

For example, when a user connects their Facebook account, they can choose to have all of their photos and status updates automatically republished to their homestead. Not shown are possible options to simply back up these but not republish them. By connecting with any of these services, the tool can also automatically determine the user's name, portrait and any other details to display on the homestead.

The final setup step consists of actually paying for the desired URL, with the assumption that the tool could arrange for free hosting. This part of the mockup isn't fleshed out much, but basically the page would show the appropriate form once the user has chosen their preferred payment method.

The result is a profile page not terribly unlike those you'd find on most social networking sites but hosted on the user's own domain and consisting of information about and from the user from a variety of sources. Their service profiles show up on the left along with their portrait and bio, and content they've decided to import into their homestead shows up aggregated on the right.

This is meant to be just a start. There are a number of ways the design and functionality of a given user's homestead could be advanced. The layout and theme could be customizable. The user could add the ability to post content directly to their homestead and then have it syndicate out to other services. They could even start creating connections with other homesteaders by adding them as friends or the like, all referenced by their own URLs.

Perhaps an open-source ecosystem could even emerge that provided plugins and other modifications to the core software package, eventually enabling social experiences that rival those of proprietary services, with feeds, messages, tags and more. The central accomplishment here would be in enabling large numbers of people to claim independent online presences with the potential to play increasing roles in their online lives. Once enough people have done so, it'll be much easier to weave a indie web between their homesteads and insulate them from the decisions or fate of any particular company.

Content

Fri, 12 Aug 11 18:20:24 +0000

People are particular about the forms of communication they employ when expressing themselves, through social networks or any other media, because different forms possess different powers of conveying information.

When in the physical presence of others, we can communicate verbally, visually or tactilely with our words, gestures or touch. Words are usually chosen to communicate abstract concepts, finger pointing is best suited to convey direction, and hugs provide the quickest route to imparting fondness.

When afar, we can send each other letters, speak to each other over the phone or route a message through a friend. The message might ostensibly be the same despite the form it takes, but a letter will likely impress a greater sense of consideration, a phone call will impart nuances by way of intonation, and a routed message will include the implicit validation of its intermediary. The transmitter must choose their form carefully if they want to get the intended message across because each form has its own abilities and disabilities to deliver information.

Likewise, social networks are constructed around particular forms of communication and consequently limited to the characteristics of those forms. The various forms can be considered types of content, because shared information persists within a given network and is intended to benefit its consumers by entertaining or edifying them. As such, it's important to consider the types of content people can share within a network as key to its communicative value.

All social networks collect identification information from their members and publish it back out as static content. Usually this consists of a member's name and portrait as well as their location and one-line biography. Particularly identity-centric networks collect a lot more static, or evergreen, information such as employment and educational history, music and movie interests, and contact details. The sum of this content is displayed primarily on a single page, which serves to anchor the user's identity within a network and provide a reference point to others. Therefore, networks share the profile as a fundamental content type.

Social networks almost universally publish some manner of relationship content, too. Friendships, follows, subscriptions, and the like indicate that pairs of people have a relationship between each other that's worth recording and making known. And the types of relationships that can be captured depend on the model a given network has implemented and how that model has been communicated throughout the service. This content – which is often showcased on profile pages but importantly delivered through notifications as well – constitutes yet another fundamental type that varies only in implementation.

The content differences between social networks, however, mainly come from the types of information that users are able and encouraged to submit as discrete objects. These types are manifold: photos, videos, graphics, status updates, blog posts, articles, documents, books, events, travel plans, travel advice, questions, answers, bookmarks, pokes, reviews, deals, goods for sale, money, vital stats, purchases, gadgets, badges, check-ins, short-form messages, gifts, songs, audio clips, polls, webpages, brands, applications and more. This content is posted proactively by users and its immediate destination is often a feed or profile page. It will likely be repurposed for other consumption points, such as search or syndication, too.

There is also a host of reactive content types that social networks variably support. These include, most commonly, comments or replies and gestures that indicate approval or disapproval of shared content, such as likes, reposts, favorites or votes. These reactive types are designed to permit direct interaction around pieces of content, allowing the publisher and any other established participant to garner feedback and increase the impact of their contributions. Furthermore, reactive content can be generated in response to other reactive content, thereby extending chains of interaction to deeper levels.

Some social networks support many of these proactive and reactive content types while others specialize in just one or a few. Support may also differ in subtle yet important ways between two or more networks, allowing those networks to convey substantially different information and consequently present dramatically different value propositions to their members.

Comparisons aside, every network must be designed around a combination of content types that can be used to fulfill the identifiable communication needs of its producers and consumers. On one side of the equation, a sufficient number of people must be interested in producing a given type of content because it allows them to express themselves in a way they find valuable. On the other, a sufficient (and most likely larger) number of people must be interested in consuming that content because it benefits them in a recognizable way.

Social network designers must identify not only certain communication needs and their corresponding content types but the frequency and size of those needs as well. Network participation requires commitment on the part of its members, lest they forget or resist leveraging it when their needs arise. And the only way to earn that commitment is to satisfy members' content needs either frequently in small ways or occasionally in big ways.

Relationship

Fri, 17 Jun 11 23:49:04 +0000

When people connect with others on a given social network, they are conscientious about whom they will connect with, because an exchange of information, both immediate and ongoing, will result from the connection.

Just as in offline life, people don't like to send and receive information to and from random people; their relationship with those people is crucial. The things you say to those you encounter on the street will differ from the things you say to familiar people in your own home. Conversely, your interest in what strangers have to say will differ from your interest in what your friends can tell you.

The types of relationships that people experience aren't simply divided between friends and strangers; they are manifold and impossible to label with complete precision. Strictly speaking, no particular relationship gets formed between two pairs of people because nuances invariably come into play. You may be office mates with both Tim and Joe, but you're a bit fonder of Joe because he invites you to lunch.

Relationships also aren't perfectly symmetrical. While you think warmly of Joe, he might think you're kind of a jerk and only asks you to join him because he's interested in your sister. Consequently, any label and assumption of symmetry you assign to a given relationship will constitute an approximation at best.

However, approximations are useful when trying to identify the type of relationships a given social network should or does facilitate, because individuals themselves map their relationships to approximate groups. And despite the efforts of designers to diversify the types of relationships that thrive on their networks, consumers tend to view each social network as primarily suitable for only one of their groups.

Understanding a group to be simply a set of people who share the same approximate relationship to each other, we can identify an array of such groups that might be facilitated by social networks. On a high level, there are expansive groups of people you've met and people with whom you've simply communicated. There are also people you admire and people you want to impress.

More specifically, there are acquaintances from colleges, companies and organizations. There are peers in your industry and collaborators on your specific projects. There are close friends whom you see weekly as well as old friends from high school you see once a year. There are family members and teammates. And there are folks you may or may never have met but who share the same interests as you.

Whatever the group and however specific, it needs to have enough members who both find the group important and desire better ways to share information with each other to warrant a dedicated network. And its importance is often tied to the group's size and its predominance in members' lives. Facebook initially took off among college (and then high school) students because it intensified the already intense relationships that existed within academic communities. Likewise, Twitter and LinkedIn initially thrived by bolstering professionally important relationships within the Silicon-Valley-centric tech scene.

Furthermore, when someone encounters a new network, it's important that they can actually identify which of their relationships it will facilitate and how they will benefit as a result. Otherwise, they are presented with the communications equivalent of a hammer without a nail; they won't know what to do with the social network and it will seem pointless. Similarly, if you signal that the network is meant for a particular type of relationship they don't have, want or care for - or if they feel as though they don't have an unaddressed communication need for that relationship - they won't feel compelled to participate.