Future of Social Network

Product Management: Attention is the scarcest resource.

2014-01-07T21:51:00.001-08:00

I have a confession to make. I don't read all my emails. I don't even remember the last time my inbox was showing 0 unread message. I think it must have been back when I was in school using Pine to check my email over 14.4Kbps modem connection. Since then I practically gave up on keeping up with everything that came my way.

In my defense, large portion of those emails are hundreds of marketing promotions, notifications of one type or another, product announcements that I signed up but never cared to read, etc. But I'm even too lazy to clean them up. (Yes, I know there are tools out there to help, but that also takes time.)

Overflowing email inbox is just one of the symptoms of larger systemic problem. I simply don't have time to consume all the information available for me. Even if I wanted to, I now realize that I don't have time and energy or will to sit down and go through them all.

I open Twitter to get a couple of gulps from never-stopping torrent of live updates. I log on to Amazon Instant Video to choose a movie from many thousands of selections that can be immediately streamed to my iPad. (I hear Netflix has even more selections. Who knows what to do with ever expanding list to watch?) I google for any information that I want, and get millions of hits available with a click of mouse. I am inundated with information. I have way more than I can handle.

All these point to one thing. It is getting harder to share messages because our attention is getting scarcer.

This is a big problem for all entrepreneurs, sales and marketing people. Our coolest product announcement is yet another spam in the inbox that can be flat out ignored. I know because I have thousands of such emails in my inbox.

Then what can we do about them as sellers? How do we make our message stick out among sea of information?

1. Reframe our perspective: Our mission is to help people get ahead, not sell our widgets.

I just don't care for people pitching their ideas without having a clue about how my day goes around, what problems I have, what I spend the most time worrying about, and my goals for immediate and longer term future. Granted that sellers are not there to provide life coaching, but at the least I would expect them to first guess what kind of challenges I have, and offer the solutions around them.

Us sellers have to remember not to treat our customers like yet another account to close, but someone who we can help to get ahead.

This also means if we cannot help a customer, we may refer him to someone else who might be able to help him.

It's about whom we can help and how we can help them. It is not about us and our widgets.

2. Invest our own scarce resource: Spend our own attention on customers.

If we realize that our scarce resource is attention, then how could we expect customer to invest their resource to open up our automated spam mail that was generated by the latest marketing campaign program?

Before asking customer to invest their time and energy, spend our time to find out about customers and trying to understand what's bothering them the most. Pick a problem that we can solve for them, and talk to a few willing customers who need the solution now. Once customers understand that we are genuinely committed in helping them solve their problem, they will return the favor by investing their attention in us and our product.

Don't expect customers to start paying attention just because our product offers freemium model. Cost to customers is not zero because they have to go through the trouble of test driving our product.

3. Make personal relationship with customers.

No one likes to buy things from someone unknown. If I had a choice of buying from someone I know or someone I don't, I'll always go for someone I know. Even if I had to pay a bit more for the same product, I would choose to go with someone I know, provided that I like the seller.

It's the same reason why it's good to have a trusted mechanic. A mechanic who knows my car history and demonstrated trustworthiness with earlier work is a more attractive choice than trying to find someone new based on the lowest price or friend's recommendation each time. If I like the guy, it's an even easier choice for me.

Be a helper to customers first. Then become a friend to them. Earn their trust and build relationship that can last. It will pay for the investment itself and many times more by returned visits and their references.

Now even if marketers are doing all these, someone like me may not be the best person to market to. Only if I can share what my iPhone email client was showing the other day with all the spammers... (Luckily it turned out to be a bug that fixed itself shortly.)

Wow, 2.1 billion unread messages!
What did I do to deserve so much love!

5 invaluable lessons that I learned in 2013

2013-12-23T23:58:00.000-08:00

It's December. We are at the final pages of 2013. When I look back at the end of year, it always feels like everything happened so fast. A year goes much faster than a lazy Sunday afternoon. Some moments make you feel like you have too much time on your hand. In reality, time marches on whether you are spending them wisely or not.

One thing that I realized over time is looking back and learning from them is really important. When you are heads down in the trenches and working on details, it is too easy to lose track of what you are doing well, and what you are not doing so well.

Especially this year, I made many mistakes (or I should say I realized I was making many mistakes). Some were expensive mistakes both in terms of my career and in terms of becoming a better person. I'm sure all these mistakes set me back a few years of trust that I built up, and I know I will have to work harder to earn them back. I want to make sure I write these lessons down so that I am fighting the right battles. Fighting hard is important, but whether you are fighting the right battle is much much more important.

I want to share with my future self and others around the web the lessons that I learned from my mistakes of 2013. Hopefully I become wiser by remembering them. Maybe some of you can learn to avoid my mistakes. Or at least feel better that you are not alone in making them.

Lesson 1: Tell others what you'll do, do it, tell others what you have done.

If tree falls in the forest and no one is there to hear it, it is just as good as not happened at all. I didn't realize the importance of communication. I struggled to share things. Maybe it had to do with my introverted personality. Maybe it came from my Korean upbringing where I believed that greatness of a man comes from working quietly whether someone notices you or not. I didn't know why exactly (and I still don't). But I didn't like talking about what I was doing.

This keeping things to yourself went beyond not seeking recognition. Often I would not say things even when someone brought up a topic that I was working on. I thought "hey, I'm working on that secretly, and soon I'll surprise all of you with great work that I did undercover." I felt smug that no one had an idea as great as mine, and no one else had all the background to solve the problem that I was going to solve it myself soon.

When I finally came up with something, I would tell a few, not all. Only deserving few could hear of my great work. The rest who I thought weren't as smart as me, I did not bother explaining what I did. I thought it was waste of my time and energy to sit down and trying to raise the group average.

What a total mistake that was.

My logic was wrong at so many levels, and it took me a very long time to untangle the entire clusterf*ck. I'm still recovering from this disease, and I have a long way to go. But I know enough to realize that this was hopelessly wrong way to go about things.

First, no idea is any good if no one else understands it. If all I was interested in was intellectual masturbation of making me feeling smug, then yes, I'd been doing a good job at it. But I was not interested in creating something just for myself. If all I wanted was something that suited me, I could have done that all day long sitting at my desk. It's called daydreaming. Instead, what I wanted to do was create something useful. Something that people could appreciate. And there is no way to do that without telling people about it.

There is one more very important thing. I realized that surprise is not a good word in world of business. No one, I mean NO ONE, likes surprises. When things go bad, everyone wants to know as early as they can, so that they can prepare for the bad news. When things go well, everyone wants to know as early as they can, so that they know how to repeat the success and continue investing on things that are working well. This is especially true with management team. They must know what's going to take off, and what is going to fail as early as they can so that they can plan things accordingly: take a closer look at failing projects, identify root cause, reallocate resources to more successful one, etc.

Yet there I was. Hoarding information and refusing to share them. From organization's perspective, I was information black hole. Taking everything in, yet refusing to share them. What a dumb idea.

Whatever you do, communicate. Tell people about your idea, do the things that you told them, and tell them about what you did. Communicate among peers, communicate out to customers, and communicate up to managements. If things happened that no one knew about, it is as good as them not happening at all.

Don't be an information black hole.

Lesson 2: Don't imitate something that you don't feel right about.

I am good at imitating. Thanks to my insecure self as a young kid and emigrant life as a high schooler, I learned to quickly imitate others and blend in when I needed to. It was a survival skill that I learned over time. I became a good observer and mimic people around me to gain acceptance and approval.

As much as this skill can be an asset, I learned that it could be detrimental to becoming my own self, someone that I can be proud of at the end of each day.

Whenever I was thrown in a new situation I looked for models around me to get me started quickly. Often it was my peers and my boss. I looked for things that I could pick up and imitate, and would carry them out without thinking about what that meant for creating my own self. I became an extension of my manager's interactions with me. I would do things because it would be expected and acceptable within the organization without really thinking about whether I agreed with them or not. I was turning into a robot that was doing things to fit in, and get approval even deep inside I did not want to perpetuate certain set of behaviors.

That was a wrong way to go about it.

At the end of the day, when I laid down on my bed and thinking about how my day went, it did not sit well at all how I behaved. Even when everyone around me accepts me, ultimately I must be able to accept myself for what I did. If I don't feel right about what I did, I should stop.

Be yourself. Use your own moral compass. No one is going to be there to comfort you when you are at your death bed not happy with whom you have became. If things don't feel right to you, stop.

How you influence people around you, how you make them feel, you are going to be remembered by those things, not so much by how much approval you received. If you are not happy with how you make coworkers and customers feel, change it. In the end, you are responsible for your own action.

Don't forget that even your greatest role models have flaws. Be selective what you learn from people around you.

Lesson 3: Follow up relentlessly.

I remember running into a friend of a friend on church parking lot. We were not that close, and did not hang out too often. But that Sunday morning, I don't know what got into me, I made a suggestion.

"We should get together for lunch or something."

I think it must have been the recent pregnancy of his wife, and I was talking to him about how my wife was also pregnant with our first child. I did not know anything better to say since we were on hi-bye type of relationship for a while, and thought it would be a nice gesture to suggest something. That was the best line that I could come up with at that time.

"Well, I don't think we can. My wife is having bad morning sickness."

When I made a suggestion, I was not really thinking about following it up. I was thinking that making a lunch suggestion would be a good way to end a conversation. It was not so awkward way of saying good bye. But he thought differently. He took my word at face value, and replied that he won't be able to.

At the end of this short interaction, I felt embarrassed. It made me realize that I was saying things that I couldn't really keep.

Trust is built on top of following up. If I said I was going to follow up, I have to follow up. Even if it was a hallway conversation or chitchats that we had by the water cooler, I must do what I say, and say what I will do.

People will come to trust you, and reward you with more important responsibility. Responsibility does not fall on your lap one day. You have to warn it by building trust.

Lesson 4: Be helpful to people.

Everyone is looking for friends who can help them. First be a helpful friend to those who are looking for one. Finding them is easy. Just look at your ever growing inbox. Whenever I miss an email that was directed to me, and not respond, I am missing the chance to be helpful to someone who are looking for an answer.

If people ask you for something, be the first to respond. You never know when you will need to ask help from them. Help them do things that they are supposed to do. Help them do their job better. If you help others, your team will do better. You'll have a tighter teamwork, and in the end you'll help create a winning team.

Lesson 5: Don't overwork.

This is a tricky one, because it took me a long time to realize. Working hard is not the same as working overtime.

Sometimes you need to put in 14 hour day, but don't let that be a norm, and don't let it become your routine. Quite simply you cannot afford to. I could not live on 4 hour sleep day in and day out. Maybe some of you can. But not me. Find a healthy balance that you can maintain. A good rule of thumb for me is feeling okay at the end of my day when I help my wife put kids to bed at night. Part of it is being around my family after dinner to spend a few minutes with them before they go to bed.

When I chronically overwork, things fall apart. First my body starts saying "uh-oh, you need more sleep and downtime." Then I see myself constantly looking for stronger cup of coffee into late afternoon. All the caffeine messes up sleep schedule, I end up losing sleep, and the bad cycle continues. While my body deteriorates, I become crankier. I start snapping on coworkers and customers (and even to my boss!).

No one likes to be around cranky people. Don't become one.

Give yourself enough time to recover. Be a smiling helper, not a cranky overworked cynic.

I plan to remember these lessons for a long long time for I paid a great price to learn them. Hopefully my blog will be around to remind me along the way.

What lessons have you learned this year? I would love to hear yours so that I may learn from them.

Happy holidays, and best wishes to everyone.

Don't protect yourself from changes. Embrace them.

2013-06-25T00:25:00.000-07:00

I have come across three interesting articles last weekend, and I want to share them. First one is how much we all hate the changes and tries very hard to resist them. Second is about how we all tend to underestimate the changes that we are going to go through, yet when we look back, the changes that we went through are often much greater than how much we anticipated. Third is Glenn Kelman's story about how he embraced the changes instead of protecting his ego.

For those who cannot wait to get to the punch line. It doesn't make sense to protect yourself. You are going to change so much anyway. Why not change faster to get better faster?

Story One

Jason Evanish wrote about how we share many links on social networks yet we don't pay attention to the lessons and how we can change to learn from the articles. There are simply too much information coming to us at incredibly rapid speed. We put ourselves on the information treadmill where we constantly have to keep up to just stay at par.

Often I pull out my phone to keep myself busy when I'm waiting in line for checkout counter. It has become a second nature that I check my Twitter timeline whenever I have a spare moment. I rarely follow the link to read the content top to bottom. I skim through the content while eyeing the movement in the line ahead. I'm just going through the motion because I can keep myself busy.

Jason's point is that we are all guilty of doing this to some extent because we often don't implement changes that we learn from the articles that we read. By actively looking for lessons that we can act on immediately, we can be more engaged, and actually read an article.

His stipulation for our lack of interest in really reading something: we are all resistant to changes because it takes efforts to step out of our egos, admit our wrongs, and move past our mistakes to embrace the change.

Story Two

NYTimes had an article talking about how we all tend to minimize the changes that we are going to have versus the changes that we already have gone through. When a thirty something is asked to recollect how much change he went through in his twenties, he has good idea of how much has changed. Yet when he was asked to look ahead and forecast how much changes he'll go through in his thirties, an average person tends to describe fairly monotonous shifts. With every age group, people underestimated how much change is lying ahead versus how much change they went through already.

This is interesting because it's saying two things. First, it is saying that we have no idea how we are going to change in the future. When looking back, it seems funny how we were acting infantile way. Yet when we are confronted with the question of how we'll change in future, we have little to no idea how we will change. Second is that even though we don't know how we'll change, we all end up changing in one way or another. Even when we have no idea, we are all changing in a way that we have a very little idea of how.

It kind of makes sense. If we had known how we'll change, why wouldn't we stay as today's selves? Why wouldn't we just change to that future selves or try to realize the future right away? We are going through the changes in a way that we don't quite understand today. The change may be just right under our nose. It could be our refusal to see the reality that blinds us.

Story Three

Glenn Kelman is CEO of Redfin. He is a software guy. But now he's building a real estate company, called Redfin. Last March he got on the TEDx stage and shared why he chose to build a real estate company instead of building a software company.

In order to solve the real world problem he saw the need for real people helping customers. Yet all his investors were signaling that he should build a software company that sells to real estate companies. He had a choice to make. Either stay as a completely virtual company, or to build a new real estate company from scratch using their own technology.

The fear of unknown did not stop him. He chose what he believed in, and he has been hard at work building a new type of real estate company.

He didn't take a short perspective to protect his position. He took a longer view, and decided to make the progress towards the future that he believed in.

The theme across these three articles is embracing a change. Change is inevitable. Everyone goes through them. Whether we plan for them or not, changes will happen. Yet some of us run towards the change, while some run away from the change.

Ask yourself. Are you still protecting yourself from changes? Or are you embracing them?

Product Management: Launching a new product? First go get some customers

2013-06-02T22:42:00.002-07:00

"We don't make it until you order it."
- Jack in the Box

Jack in the Box used to feature this slogan on their TV commercials. It was meant to tell customers that their food is made fresh every day. Software industry is not going to win any customer by making things fresh. But there is a good reason why just-in-time manufacturing makes sense for software. It is to avoid building something that no one wants.

It is easy to fall into the trap of thinking that we know what customers really want. In most cases customers themselves don't know what they want. They have a vague idea of what their problem is. Sometimes the problem itself is not known to them. Yet we software makers think that we know exactly what customers are looking for and will love our product that we are building.

Truth is that no one exactly knows what will work well in a real situation. We all have guesses as to what could work, but our guesses are often too far off to be useful in its first iteration. There are a number of odds stacked against any new product.

It will be the brand-new product, so it will be buggy and unstable compared to other existing solutions. It has limited features so the way it can be used will have fairly narrow applications. To top them off, it may not even solve the problem that is worth solving from customer's standpoint. It may be solving a nice-to-have problem that users are not interested in paying for.

It is easy to make this mistake. I have made this mistake a few times myself, and this is one of the most wasteful ways to spend precious company resources. Creating a wrong product does not end there. It creates a ripple effect to marketing, sales and sales engineering in order to see if there is any customer out there. It sets up for fail-slow situation, something that you want to avoid as any entrepreneur.

So instead we should first find a few customers before we jump into building it. When you have an idea of what you would like to build, first go talk to customers about it. Don't feel bad that you don't have a solution that you are ready to hand over to customers. Instead feel victorious when you identify a product idea that they are willing to spend their hard-earned cash. By talking to customers first and selling on the product before building does a few things to your product:

1. Your market is never non-existent.

Guess what. You already know who you are building your product for. Unless you screw it up so badly that they won't use it, you will have a market of a few customers who are willing to try your product. By selling first, you know who you should sell to, and get to find out solving what problem will likely get the return call from your prospects.

2. Customers can help you define how the product functions.

Having potential customers is different from having avid fans. Software market (and other markets for that matter) is littered with products that are not solving the problem that user has in an elegant way. They may get sold to several customers, but they quickly become a shelfware. Having customers involved in the product design phase minimizes your chance of creating a flop.

3. You get a much needed initial customer quote for you to get the next customer.

The first thing that any good marketer will do when putting together a product launch is to look for a customer quote. It is so much easier to get that quote if you had identified a customer who can use a solution that you just put together. Getting the customer quote takes a long time and often marketing team has to settle for getting a watered-down quote that talks about the importance of solving the problem, not about the product. When you ace your product development, early adopters will let you know by saying yes to those customer quotes.

Selling is a process of figuring out how to best help a customer. If there isn't anything that you can do to help customer get better at what they are doing, then there is no reason for you to be talking to the customer. When that happens, gracefully walk away and go knock on another door.

If you think you can build a successful product without doing this homework, then you are either a next Steve Jobs or someone who has time and money to learn the lessons the hard.

Learn from the one who learned it the hard way. Get a few customers first before building your shiny new product.

Simplify what it does to absolute minimum

2013-05-28T20:28:00.003-07:00

I like simple things. When I sign up for a service, I already have a problem that I would like to solve. What I look for is the quickest path to solving the problem at hand. From user's perspective it should be dead simple. Simplicity of user experience means that someone else took the trouble of thinking through the intricacies involved in solving the problem, and laid it all out. As a user, when I discover a simple product, I am thrilled.

There are different aspects to creating something simple, however. Creating something simple is anything but simple. There are three aspects that I can think of:

Problem that the product solves
Product UI and UX
Implementation

If the problem solved by the product is too trivial or too simple, then there may not be customers who are willing to pay to solve the problem. So problem has to be complex. In fact many entrepreneurs and VCs recommend going after a big and complex problem. More complex the problem, the higher huddle will be for other competitors to follow you and better the chance will be for customers to pay for the product.

Product UI/UX and implementation on the other hand should be as simple as they can be. It is important to note that the product UI/UX (customer facing experience) is different from implementation complexity (internal parts). To use home builder's analogy, product UI/UX is the paint job and decorations on the wall while implementation is how the house was built, electrical and water pipes are laid out. Both are important for different reason. But the end goal is to simplify product UI/UX so that users can easily pick up the product and start using it. Implementation simplicity is there to support this activity, so new addition to the house can be easily added with minimal cost.

The products that I am thrilled to discover are the bottom two types of products. It solves complex problem, yet offers simple user experience, and it evolves quickly to become even more useful in a short span of time.

Of course as a user I have no idea whether implementation is simple or complex. But what I often observe is that a great product evolves fast and the only way they can do that is by keeping their implementation simple enough so that they can execute fast on product UI/UX enhancements and possibly add another problem to make the problem even more complex.

Where does your product rank? What's your next step?

Product Management: When to add a new feature

2013-05-19T23:25:00.000-07:00

When do you add a new feature as opposed to improving the existing feature?

Past week I had a chance to spend time with a bunch of customers. It always gives me a new perspective, a perspective that really matters to the company, i.e. the reality.

Customers care about their unique problem. They might not be at the stage where they can make use of all the product features. Their users may not have been trained on all the features, they may not have the browser version that supports the latest feature, or their internal roles may not have been set up the way product was designed to support. Or they may not even know about the capability of the product.

Each customer is at different adoption curve. They have a different set of problems they are dealing with. When they are having user adoption problem, they are not interested in hearing all the great features that the product has to make it easier to scale the roll out.

Because of the unique customer perspective, many customers have their wishlist. It is a list of enhancements to make their jobs easier.

In addition there are other new features that you are working on. These are bets that you are making to solve customer's problem in a new way. By definition these are features that no customers have asked for. You are not even sure whether it can be used by customers. (If you are sure it is going to be a success, either you are smoking something or a real beginner PM.)

Then the question arises. As product manager, how do you decide when to work on improving existing features versus working on a brand new feature?

It depends. There are times when improving existing features makes total sense and there are also times when investing on a new feature makes sense. That's because expected return is different based on the product maturity and competitive pressure.

If you have a relatively new product that is looking for customer validation, it makes all the sense to invest resources in improving the existing features because they are not yet proven to be useful to customers. If you have a mature product that is getting commoditized by competitive pressure, it makes sense to add a new feature to differentiate your product from the rest.

Key to which strategy to pursue doesn't end with a decision to invest in existing features or building a new one. It must also include how to measure the success once the strategy is implemented. If the feature is enhanced per customer's request, there must be a follow up with the customer to ensure that they see the value. It's a great opportunity to build relationship with the customer who requested the enhancement and earn their trust. You would want to create metrics to ensure that the enhancement can also be applicable for the rest of customers, and measure them.

Same is true with a brand new feature. If decision was to pursue a new feature, then its adoption and usefulness must be tracked so that it can be improved with each iteration. Make sure that you include a few customers in your study so that you get a view of the reality.

Note that introducing a new feature is a lot riskier than improving existing ones. I recommend that you consider the following points before making the decision:

Keeping customer happy and not losing them is 10 times easier than winning them over once they leave to competitor's solution.
Adding a new feature and getting it adopted tend to get underestimated. It is a factor of magnitude more expensive than improving existing features.
Pursue *only* the enhancements that can be widely applicable; pursue *all* enhancements that can be widely applicable.
Do cheap enhancements first; not all enhancements yield the promised user experience benefit.
Understand what enhancement the customer is looking for and why; there may be other ways to solve the problem.
One easy test to validate the viability of enhancement is to sell the idea to other customers.

Hope this has been helpful to you. If you have comments or feedback, please let me know at jaeho9kim (at) gmail (dot) com. If you are on Twitter, please follow me: @jaeho9kim.

Facebook Trusted Contacts & Mother's Day Notification

2013-05-12T23:27:00.000-07:00

A couple of weeks ago, Facebook rolled out a feature called Facebook 'Trusted Contacts'. Instead of relying on security questions and two factor authentication, Facebook is saying that they can solve the problem by using social graph. Facebook is thinking that our identities can be verified easier by sharing the secret codes with our Facebook friends. They can forward the codes to us, and we can enter them to regain access to our Facebook account.

A neat idea on the paper. I like the idea of password-less login. But asking them to send me a secret code that they received just so that I didn't choose to pick my security question or enter mobile phone number? For me, the pain of bothering someone to solve my forgotten password problem is greater than regaining access to my Facebook account.

What about this push notification that I received from Facebook Pages yesterday?

Push notification that I got from Facebook Pages yesterday.
Sorry, Facebook. My mom got a phone call from me instead.

First of all, my blog page is the only active Facebook Page, and it is all about social media, product management and startup. I haven't posted anything personal about my mom, nor my mom visits my blog page (I don't think she even knows I have a blog). Somehow Facebook felt that it would be a good idea to post something because it's Mother's Day. I think it would have been more convincing if it said "post something today; if you don't like to post today, hey you can always schedule your post!"

Second of all, I got this message as a push notification. Unsolicited push notification is by definition spam. Not a good way to encourage people to use more of Facebook.

Facebook has always been moving fast and breaking things. That's what I like about Facebook. They are not afraid of trying new things, seeing how users react, scrap the whole thing if the outlook is not promising, or forge ahead if they see opportunities.

But even for Facebook, the master of trying new things, is not as fast as 4-person startups. Even with their engineering resource and well-disciplined teams, they cannot focus their energy on multiple fronts.

I'm not surprised at the rate that Facebook is churning out new duds. I'm willing to bet that their rate of success hasn't really changed since they opened their door. What has changed is the rate of evolving customer taste and the social network plumbing that enables faster dissemination of new information (think of memes of various kinds, PSY's a-billion-viewer YouTube hit, to name a few).

In some sense Facebook is falling victim of its own success. Because of Mark Zuckerberg's proof by construction, Facebook, it is now easier to create viral hit, and even yet another viral medium. Now people understand what they are capable of.

I haven't signed up for Facebook Trusted Contacts or ended up making Mother's Day post on my Facebook Page. But I know that doesn't mean Facebook will give it up. Maybe next year I will see my Mother's Day reminder with rose bouquet delivery option to my mom with custom Facebook invite message. What about that as a feature request of 2013?

How to run a small business

2013-05-05T21:54:00.000-07:00

Yesterday I dropped off my wife's car for an oil change. My mechanic is a small independent one. He is a typical small business owner. He always has greasy fingers and runs between his tiny 6-by-6-foot office and the next door repair shop. When the office phone rings, he is the one picks up the phone to talk to the customer. Often despite his best efforts he answers the phone after several rings because he has to rush to the office from the repair shop.

When I dropped off the car, the shop was busy as ever. There were three customers waiting to speak to him.

After waiting for my turn, I asked him.

Me: Time to open a new shop.

Him: No, I don't plan to. Let me tell you in a bit.

[He had to run out to get another customer's car ready. After he returned he asked about what I wanted him to do on the car. Then he picked up the topic.]

Him: So about the new shop. I am not thinking of opening a new shop because I will then have to hire another service manager. Then I won't get to talk to my customers. All I will be able to see is numbers at the end of each day. You come to me because I treat you like my family members. If I open a new shop, it won't be the same way anymore. Because it will all be about numbers, new service manager will be encouraged to sell what's not needed to customers.

Me: Right.

Him: That's why service managers in dealership become dishonest and sell you things that you might not need. That's why people call it stealership instead. [chuckle]

Me: You know, I may quote you there.

What my mechanic described was two classic challenges that any small business including startup entrepreneurs run into all the time:

Ultimately business is built on the trust and relationship with customers.
It is damn difficult to scale a business and keep the same level of customer service.

It's easy to forget that we like buying from people that we trust and have relationship with. And it is even easier to forget that the same applies to enterprise software business. In any purchasing decision, there is a customer who is willing to invest in the relationship and trusts the software vendor. Key is to make sure that the customer feels that the relationship growing and the trust is built upon.

When customers can engage with the vendor and can see that the vendor's care for them, they will come back.

But often what ends up happening as we scale is that we the vendor forget why we are in the business in the first place. As we scale and make new hires, we tend to chase the quota and numbers. We let our eyes off of the most important metrics, our customer's satisfaction.

It is a very difficult problem for all organization. I haven't seen any startup advice that doesn't talk about the importance of hiring the right people and keeping the culture of excellence.

My mechanic knew that difficult challenge. His solution was to stay small and invest on strengthening the existing customer relationships.

I have to mention that he also offered to lend me his own car when I decided to keep it in the shop to take care of the low brake pads. No questions asked. Now that's a customer service that you won't see from a dealership.

Thoughts on social network and its API

2013-04-28T22:42:00.001-07:00

I have been thinking about what API meant for social networks. Social in nutshell is about identities, sharing content and engaging with readers in two way conversation. It made existing blogging concept easier to adopt and more accessible to millions of users. While popularizing publishing and subscription model with social relationships, social found new exciting applications like user-reported breaking news network, 1-1 messaging networks, and photo and video sharing services.

Blogging platforms were available well before social networks. But it took Facebook and Twitter for content publishing and subscription model to really take off. People saw what they can do by easily sharing updates with friends and families. Technology (publishing and subscription) disappeared in the background and the user benefit (staying connected with friends and families) emerged.

Social API on the other hand is all about allowing developers to integrate social network identities and social graphs stored in each social networking service. Social API is there to allow other applications to incorporate what social network has done to blogging platform. Social API made it for social applications easy to use identities, share information and get engagements from people around us.

It allowed many applications to introduce social component by plugging into social network APIs. What could have been a run-of-the-mill word puzzle turned into real-time family room board game that could be played across cyberspace. Flower shop applications knew before I did that my mother's birthday is coming up and reminded me to send her bouquet. Social API instantly allowed developers to run their applications in context of user's own social graph. These applications in turn provided richer environment for the social network and its users.

Developers could focus on building the best possible applications within their domain. They no longer had to think about how to collect social identity and social relationship data. All social data were already provided to the social networks by many millions of users, neatly formatted into JSON structure and available to be integrated into their applications. Social API is what made many thousands of applications to be social without creating their own social network.

This led to explosion of social applications. Everyone started integrating social API. Zynga made business out of applying social API to simple board games. Websites integrated social widgets to share information to and from social networks. Allowing visitors to share the content through social networks became a best practice among SEO-minded sites.

Social API was not just a boon for application developers and users. Social API is what allowed social networks to collect additional data without investing whole lot of resource on developing the next Farmville. By allowing social data to be accessible via API, social networks could collect application usage information and monitor the submitted data. In effect social applications were paying the networks by providing usage data on user's behalf.

Then when social applications began to take shape of their own social networks the social networks took a notice. They revised the API terms of use to ensure that APIs could be only used in a certain applications. In effect social networks started to dictate kind of applications that are allowed on their social API. The API capability remained the same, but developers have to think twice whether their application can possibly run into the network's business model today and tomorrow.

Now social API is not what it used to be. The incentive for super social networks like Facebook and Twitter to share social data and get paid by data in return from the applications is almost zero. They have their sight on monetizing their user base and traffic, and their focus shifted to winning the mobile user's choice as the most popular apps of their own. Social API is no longer the growth strategy that will move the needle for these super social networks, and it started to show up on their business decisions.

It is not yet clear that developers have an alternative. They can either go with super social networks knowing that their application could be disabled as a competing product, or they can go with smaller up-and-coming social networks that caters to social networking users and application developers, or choose not to integrate social component. None of them are good choices from developer's perspective.

Most developers are still going with super social networks because the other choices are not acceptable one. While they are aware of the risk, lack of alternative is leaving them no choice but to work with them. But because of uncertainty, many app developers are hedging their bets on multiple networks or not entirely dependent on one social network as their distribution channel. This means new and exciting apps are increasingly not entirely relying on super social networks to get themselves bootstrapped. And this is further eroding the richness of social application ecosystem available on top of social APIs.

I am actually quite excited about the changes ahead. This means there will be more diversification of social networks, therefore I am hopeful that more context-ful social networks will emerge in the future. And I am wishing that the next time around, social APIs will be designed and maintained with users and developers in mind.

Product Management: What I would expect from API

2013-04-21T22:04:00.001-07:00

Thanks to slower pace blog update, I have been able to spend a hour a few days a week to pick up hacking again. I would call it hacking, not coding, and I want to draw distinction between the two because I see the difference. More on that later.

The project is migrating email to collaboration platform. I blogged about it earlier. One sentence description is to take emails in Inbox and post them on enterprise collaboration platform to be shared to internal audience. Minimum Viable Product is posting the emails that I select on my Outlook client (yes, I'm the user of this product) to collaboration platform, and have collaboration platform return the link where it's posted so that I can forward it to anyone who need to be included. Tagging the email so that I can search easily would be nice as well.

I use Outlook client for my work, and in order to access Exchange server, I had to use C#. I've never coded in C# before. I don't know any C#, and that's where my hacking began. I call it hacking because I didn't sit down to learn C#. I had a specific goal that I had in mind, which was to use Exchange Web Service API to access Outlook Inbox messages with special tags. I had to figure out a way to do it using C#, a language that I didn't really care to master, so I had to hack something together. That meant I relied on Google extensively to code and troubleshoot compilation errors. I began from working code sample, and what I have still very much resembles the sample code from MSDN. All my hacking was done on Visual Studio, and much of credit should go to autocomplete feature of Visual Studio.

While I was doing this hacking, I learned a few things. I wanted to share them with you to see if any of you felt the similar way. What I'm about to share is hacker's perspective. Someone who doesn't know the language or doesn't care to learn the language. All they are interested in is getting the stuff to work.

These are things that I learned.

1. I don't have time to learn new language.

I was not interested in picking up a new programming language. The fact that the language that I had to use was C# didn't help. I cut my teeth writing Java and C as a coder. I decided to work with them early on because they were free and open. It meant I didn't have to go get a license just to write some code or distribute the source. I wasn't going to pick up Microsoft standard and write application that would only run on Windows environment.

Instead I was much more interested in coming up with a solution. I had a goal of building a tool that solves a problem that I had. C# was a means to help me create the tool.

2. I want the sample code to just work.

Because I was dealing with a development environment that I was not familiar with, my strategy was to start with a sample code and start morphing it into a tool that solved my problem. I had a simple reason. If I start with sample code that already compiles and runs, I wouldn't have to worry about picking up the language syntax, going through the Hello World example, and fix compilation errors.

There were just one problem: sample code had to work as advertised. I picked up Exchange Web Service API sample code (retrieving Out-of-Office message sample code via EWS API), and built and compiled. Thankfully it compiled without any error, but when I started running, it didn't run. It turned out that auto URL discovery for Exchange service did not work in my environment for some reason. I had to find out what the service URL was and populate the URL manually.

Another bug was more subtle. When the sample code was run, it prompted for email address. But in reality it was expecting the user to type in username not the entire email address. It meant when I typed in username@mydomain.com, it failed to connect to our Exchange server consistently. Only after poking around and several google searches, I realized that it was expecting username only without @mydomain.com. Duh.

All it needed was a simple print message "type username of your email address ('john.doe' if your email is 'john.doe@domain.com')".

3. I want the API to be as small as possible, so that I don't have to invest time to figure out things.

As the sample code started compiling and running, I thought I got over the hump. I was wrong.

When I looked for reference guide for Exchange Web Services API 2.0, I knew exactly what I was looking for. I was looking for a way to save the message based on an extended property. But there were no place where I could find that enumerated all available methods from EWS objects.

I think the idea of organizing the doc by the tasks that developers can do with the API was a good one, but it was only as good as sample code and comments explaining how they worked. For example, the sample code to retrieve extended property by name did not work, and it didn't have line-by-line explanation of how the code was supposed to work, I had to rely on google to save the day. To make the matter worse, there were no enumeration of methods. I just couldn't figure out how to manually construct my hack.

What I had to rely on was many google results and Visual Studio suggested methods to find the right solution. That was not fun.

4. I want my answers to be Google-able.

Only saving grace was that there were other developers who shared their code and suggested workarounds. Without their posts and comments, I simply did not have a chance to even get over the first hump. Imagine doing this soon after the API was released without all google results. I would have given up after a few minutes.

So what is the lesson for those who are setting out to build their own API? Here's my take away:

When building an API, use widely understood and easy to use language. Don't make developers to learn new environment to use the API.
Make sure sample code runs as is. Chances are that will be the first thing any newbie will try.
Explain the sample code line by line so that people who don't know the language can still hack up a solution.
Keep the API set as small as possible and make them searchable. The smaller the API is, the more refined the API is.
Create searchable community where developers can leverage each other's knowledge.

Hope this has been helpful to you. If you have comments or feedback, please let me know at jaeho9kim (at) gmail (dot) com. If you haven't, please follow me on Twitter: @jaeho9kim.

Product Management: What hiring manager looks for

2013-04-14T21:49:00.001-07:00

The other day I had a chance to sit down with someone who was looking to get into product management role. He shared his experience of applying for product management positions, and I shared with him how I got into product management role. I told him that I began my career as coder, then professional service guy, back to engineering as development manager, and only after that the opportunity landed on my lap to try out product management role.

Then the topic turned to what I look for from product managers that I hire. I thought that might be help him get some perspective on what hiring managers look for and what areas that he should invest his time to land a product management position.

After sharing my perspective with him, I thought my blog readers might be interested in what criteria that I measure PM candidates.

There are three areas that I look for from PM applicants. Note that I consider all three areas to be equally important.

1. Discipline to learn domain knowledge quickly

PM owns the product. Any product has a problem that it solves, and it exists in a particular industry. Almost always there are competitors. Often competitors include do-nothing option or customers using the existing products in creative way to solve the problem. All of these scenarios should be understood by PM.

They begin from PM understanding the problem, competitors, industry trend, consumer taste and technologies available to solve the problem. It is so-call domain knowledge. All successful PMs have in-depth domain knowledge. So it's natural for hiring manager to look for domain knowledge.

I look for two aspects to measure the domain knowledge from candidates:

Either they show that they already have domain knowledge, or that they demonstrate the earlier track records of picking up the required domain knowledge fast.

Say you worked for social media company as sales engineer, and you understand the social media industry. Right out of the gate, you are uniquely qualified to apply for social media product management position. All your customer interactions, competitor's information, and available technologies would be directly applicable to a product management role in other social media product companies.

But that's not to say that you cannot apply to the position if you don't have the prior social media experience. What you then need to do is to demonstrate that you can quickly come up to speed. There are multiple ways to do this. One way is to launch your own startup idea in the social media field. This is a classic way of learning by doing, and you can read more about how to do them on my three-series blog posts.

The other way is to share your views and lessons about the topic. There are many ways to share ideas and content. The best way is to create your own blog and start sharing content through the personal blog. That way, all contents can be found and can be easily attributed to you, and people on the web can benefit from your work. Plus when the interviewer asks a question about your domain knowledge, you can point them to the blog as your referenceable work.

2. Prior product management experience

When I scan for product manager candidate, I always look for product manager keyword. That's because I want someone who has been around the block and knows something about how product management works.

That is bad news for some candidates. Especially for someone who does not have prior product management experience to highlight. But there is also good news. It is now easier than ever to find resources to teach yourself how to be a good PM.

There are many wonderful resources around that help you take a peek into what a PM should do: SVPMA (Silicon Valley Product Management Association), many product management and startup blogs, Product Camps, StartupDigest, many product management and user experience books, to name a few.

To test product management competency, I often ask questions like the following:

What is the number one job of a product manager? Who does a PM interact with to get the number one job done?
There is not enough data to make a decision, but the engineering team demands the requirement to be specified. How would you come to a decision? Would you collaborate with anyone?
Product development is about to hit the feature complete. While doing a beta testing, beta customer demands a last-minute feature request. What do you do?
Engineering team just delivered FRS with 3 man months of work estimate to develop the feature to your requirement. What is your next step?
Executive team suggests a new product idea. What needs to take place to launch the new product?

3. Capacity to connect with customers and all departments

Product manager is at the center of any product organization. PM must be able to communicate with everyone in the organization. If there is any hindrance in communicating with other department such as personality issues, too big ego, inability to listen attentively, and ability to earn trust from other team members, then it will eventually show up some problems. Often they show up as lost deals, incorrect customer expectation or even worse solving the wrong problem with a new product launch.

That's because PM is at the central hub of all communication paths.

Customer's requirement needs to be translated into product requirement and gets communicated to engineering team. Support team must understand the product behavior ultimately from PM, and PM must listen to problems that customers are having from support team. Marketing team must interact with PM to create product marketing materials, and find out what messages are resonating in the market or not. Sales team must be able to signal to PM the upcoming opportunities and influence the feature priorities, and PM must be able to clearly communicate what features are coming up in the future releases. Exec team needs to understand what the product strategies are and how the product is progressing in implementing the strategy.

PM is a role where information needs to constantly flow from one department to another. And as the number of people PM needs to interact with, there are bound to be some who are not as easy to speak to, have different point of view and what PM's role is really about. Even if there are differences in opinions, style of work, and personality, PM must be able to keep the information flowing.

PM must be able to encompass the entire organizational team in sharing product behavior and vision. Perhaps it is the second most challenging position to HR in dealing with different departments and many personalities.

Hope this has been helpful to you. If you have comments or feedback, please let me know at jaeho9kim (at) gmail (dot) com. If you haven't, please follow me on Twitter: @jaeho9kim.

Slowing down the pace

2013-04-07T21:39:00.000-07:00

When there is time to start, there is also time to stop. I remember my college English professor's definition of self control.

Self control is knowing what to do, when to do it, when to stop, and doing it.

It's little over two and half years since I've started blogging on Future of Social Network. Starting January 2012, I've committed myself to write every single day to improve my writing and get in the rhythm of daily writing routine. Just like I've decided to write every single day on the spur of the moment, I have decided to slow down my blogging schedule.

Instead, I plan to blog once a week. I want to try this schedule for a few reasons:

1. Be more deliberate on what topic to post.

One thing that I learned in the past 15 months of blogging every day was the difficulty in writing when I have trouble choosing a topic. There have been many days when I sat in front of empty monitor and stared at the blinking cursor for half an hour trying to come up with something worthwhile to write about. I originally started writing about social networks and their trends, but I rather quickly ran out of interesting things to say about what's happening once I started doing it every single day.

Since then, I have expanded my blogging topics to include product management, startups and interesting bloggers to follow. Even then I remember forcing myself awake to scribble something down. Often topic was decided to fill in the gap instead of choosing one that I felt would be meaningful for the blog.

I want to change that now. I want to be more deliberate about what topic that I talk about. I want to allow myself more time to choose something that I think makes sense for this blog.

2. Increase my writing efficiency.

It was not always hard slogging to write a blog, however. Sometimes it only takes enough time to type out my thoughts. Words just flows out from my head through my shoulders, arms and fingers, and ends up on the screen. They fill up before realizing that there were enough materials to write something about in a blog. That is what I would call being "in the zone."

When in the zone, it's so easy, fast and efficient to write things down, it is easily 10x more efficient writing a blog. I found that to be in the zone, I have to know what I want to write and get the skeleton down so that I can quickly flesh them out to make a cohesive argument. I want to write like this more often and increase my writing efficiency.

3. Allocate time to pick up coding again.

I also want to spend more time writing code. I have been thinking about a few worthwhile open projects to start. Cataloging interesting bloggers to follow, helping enterprise transition from email to collaboration platform, and creating a open platform where inefficiencies and improvement areas can be reported and shared are a few that I've been thinking a lot about. Each of them I've started to tackle in a small way, but I want to spend a bit more time so that I can actually use them to improve my own life.

Hopefully picking up coding will give me new materials to write about. Already I have collected a few helpful tips to share on Exchange Web Services Managed API 2.0. Maybe I'll write about what I learned from doing some hacking.

So, there you have it. It's a bit of bittersweet for me to move on to the next phase of Future of Social Network. I feel a bit sentimental about the fact that I won't be able to track my progress with daily blog post. But at the same time I am excited by the prospect that I will have more time to work on my open projects.

In the end the goal of Future of Social Network stays the same. It will continue to be about social networks, product management, startups and blogs. Now that I have more time, you may find an entry or two about coding as well.

Sachin Rekhi: Being entrepreneurial product manager

2013-04-06T21:55:00.002-07:00

Sachin Rekhi is a serial entrepreneur with product management background. He founded Connected and Feedera which got acquired by LinkedIn. He is also a coder and writes about API platform and how to build developer community.

He has been blogging since 2009, and he has shared product management and lessons he learned from his startup experiences through his personal blog.

Here are some blog entries that I found helpful:

One that resonated with me the most was solving the different pieces of problem for three constituents to get developer platform going. There are developers who want to build their fame and livelihood on the platform, end users who want to solve specific problems, and platform provider who wants to create vibrant application ecosystem that provide additional revenue stream. The difficult piece is to create a win-win-win situation for all three so that there can be positive feedback loop among all constituents.

In order to create a vibrant developer community, first there has to be clear incentives for developers to invest their time and energy in building applications. There must also be users who are interested in using the applications developed by the third party developers. Sometimes the development or integration work starts out by having users funding the efforts. Regardless, what is important is that two parties must find incentives to work with the platform.

Then finally there is the platform provider. The developer support and API servicing must be economically sustainable.

I wanted to share Sam Ramji's comment from the last Wednesday's SVPMA panel discussion talking about API platform strategy. I'm paraphrasing:

There is no API business model. It depends on your current business model. API is wrap-around distribution strategy that allows you to scale using external developers.

Facebook Home and privacy concerns

2013-04-05T22:12:00.000-07:00

Facebook announced Facebook Home application yesterday, and there have been discussions around what this means to Facebook users. Om Malik wrote about how Facebook Home will be used to track user information without their consent. Robert Scoble responded with how benefits will outweigh the loss of privacy, asking privacy-concerned users to get used to being constantly tracked. After reading these articles, it made me think about what it all means to me the user.

Privacy concern is real. We are all being tracked, and it is only going to increase. At least both Malik and Scoble agree with that trend. With proliferation of connected mobile devices with camera, GPS and dozen other sensors, we are generating more data than ever before. And the trend is accelerating.

I don't think anyone fully realizes what it means. That's because we never lived in a world where most of everything that we do are tracked, aggregated and analyzed.

Yet this is not an entirely new phenomenon. Each time new major technology shift happened we had to adjust our way of life, and life went on. When movable type and printing press were invented, ruling elites were concerned that they would no longer be able to monopolize the knowledge, and took measures to censor and limit the reproduction of printed materials. When nuclear bomb was invented and dropped on Hiroshima and Nagasaki, Americans and Russians thought that having more nuclear bombs would give them greater power to control the other.

What is undeniable is that our yesterday's notion of privacy as we knew them will no longer be applicable very soon. Digital identities on Internet will be extension of our real identities by default. In addition it will have lots of data about us than we ever care to admit. That is going to be the future. Anonymity will only be available to those who actively hides their identities, and even then the odds are stacked in favor of data collectors and marketers.

We are all going to have to deal with our digital identities. Unlike our real-life identities, they are permanent and traceable. They are just different from real-life identities. We never had to deal with identities that could be mass collected, easily replicated and analyzed.

I think we will all eventually learn to deal with this change. Just like we got used to the idea of printed books and nuclear weapons, we'll come to accept the fact that we'll be tracked and the data will be collected about us.

But what's important is that we should all be aware of what data is being collected, and when we can decide to get off the tracking by companies that we deal with. It's going to be about trust between the company and the users.

Concerns about privacy is about the concerns of missing trust. Because there is no history of how the massive data about us is going to be used (for us, against us, or, most likely, for someone else's gain), we have to be able to trust the company who collects our information.

The debate about privacy concern is fundamentally about loss of users' trust.

Transitioning from email to collaboration platform

2013-04-04T23:01:00.000-07:00

Transitioning from email to collaboration platform is a difficult problem. Technology of deploying collaboration platform is easy. What is difficult is getting people off from email and have them start using collaboration platform to start realizing the benefits of shared virtual group page.

As I wrote earlier in my blog post, I have been thinking about this problem for a while. This week, I've decided to look into a simple module that would make this transition easier.

Minimal Viable Product is a simple one. As an email user and collaboration early adopter, I want to start posting emails with long To and CC list to an internal collaboration system. The system will keep track of single master copy of the email thread and recreate the thread by timestamp. That's it.

No authentication to access control the email (most organizations are suffering from lack of information sharing, not from too much sharing), no fancy threading (people can make out who replied by looking at the email body sorted by timestamp), no sexy UI to render the email content (most people are still used to Outlook that has not changed much when it comes to reading emails), and no support for replying to email from the collaboration site (we need to take one step at a time; people are not simply logging in to collaboration site to look for the latest information).

What I need is a dead simple way to get my email thread out on collaboration system, and for others to do the same. Email recipients should have a choice of uploading their email to a collaboration site, and once uploaded it should be available to everyone who wants to follow the thread. Any subsequent email exchanges should automatically reflected on the collaboration system. Oh, and we cannot forget to notify all the recipients that the email thread is now hosted on collaboration site so that they can look at the latest discussion at any time.

It also musts support many internal collaboration systems. That's because collaboration system market is highly fragmented, and there is no sign that there will be any one dominant player unlike corporate email systems (refer to the Enterprise Social Market Share 2011).

So I wanted to ask you. Would something like this be useful to people? Do you know any solution that does something like this?

If so, I would love to hear from you.

Support "Right to Know" Act

2013-04-03T23:28:00.001-07:00

California law makers introduced a legislation that would allow consumers to get their personal data from companies and whom they shared the personal data with. Right to Know Act (AB 1291) will require Googles and Facebooks in the world to disclose their Californian's personal data that they store, and notify their users before or after the data is shared with third parties.

If you've paid attention to all the privacy disclosure forms that you get from credit card companies, you know that privacy disclosure is already mandated for financial industries. What EFF and ACLU of Northern California are trying to do is to expand this to cover digital personal data stored by online software giants like Google and Facebook. You can read more about the Right to Know Act on EFF blog or take a look at the Assembly Bill 1291 in PDF format.

I like the approach that the Right to Know Act is taking. It's calling for transparency to personal information sharing among companies. This will allow users to make informed decisions when selecting one company over the other. As long as users have access to how company is sharing their personal data, the users can demand the change. The Right to Know Act will shine lights on how much users are indirectly paying for their freemium services. It may spark more pay-to-use services to launch.

Digital privacy is something that we have to actively protect. It's been too long where all the power shifted to tech giants away from individual users. We all understand that we are voluntarily submitting our information for our convenience, but that does not mean that we are giving up all our rights on how our information can be managed and shared.

From online companies perspective, the right thing to do is to store as little of personally identifiable information as possible to provide the service.

If you are a California resident, you can use the following button to support the Right to Know Act through EFF. I ask that you do.

Click here to support the California Right to Know Act.

Twitter Cards with link to mobile app

2013-04-02T23:47:00.001-07:00

Twitter had a developer meetup and announced upcoming Twitter Cards. The concept of Twitter Cards have not changed much. It allowed third party developers to embed their rich content, such as summary of content, photo or video clip as part of the expanded tweet. But what's new was the link to mobile app where viewers can download the mobile app.

new @twitter card types: #Summary #Image #Player twitter.com/davemcclure/st…
— Dave McClure (@davemcclure) April 3, 2013

This means as tweets get passed around, so does the link to the original app through which the content was shared. Just like Facebook users clicked on click to play FarmVille link, Twitter third party developers can use Twitter to spread their adoption and maintain active user base.

Twitter has all grown up. It has come full circle and realized that it now has to compete with Facebook to compete for mobile user's eyeball time. As its final act to demonstrate that it's now fully claiming itself as its own social network, Twitter wants to be a social network that is friendly to app developers again.
I can understand why Twitter needs to court third party app developers. That's because social networks are compartmentalized by users, and there will always be smaller networks and mobile apps where people are going to use regardless of how feature-parity Twitter will be with all the other networks. But what I don't get is the reversal of how Twitter suddenly decided to be more friendly to third party developers and hope that they all come back to leverage their user base after shortchanging many developers leading up to the event.

I'm sure Twitter was looking for a way to monetize their platform, and one of them is to make money from third party developers who are using their platform. In order to do that, I guess they figured Twitter had to clean up their older API usage terms and get ready to clamp down the API access by restricting what kinds of apps are okay and what the acceptable rate limits would be.

I am not sure how developer communities will react to this. Using Twitter to bootstrap a new social application is and will be a risky maneuver because the relationship between the newbie and Twitter is such a lopsided one. Twitter is already a huge player, and upcoming social app developers will have to agree to more onerous terms to get access to Twitter user base. Relying on purely Twitter to distribute the app is not going to be the strategy adopted by many.

This means third party app developers have to think about going sans Twitter even if they work with Twitter to integrate with Twitter Cards. I'm not sure how much value this will be for the app developers.

If you are a developer, what is your thoughts on the Twitter Cards announcement?

Product Management: Looking for problems to solve

2013-04-01T23:00:00.003-07:00

I've been thinking about what problems to solve. I think there are many problems to solve all around us. The trick is recognizing what makes a problem and figuring out how to come up with a better solution.

Here's how I look for problems to solve around me:

1. Add the latest technology to the old way of doing things.

Any business created before Internet and mobile is a good candidate for disruption. Think of how you might approach solving the same problem with new technologies. Think about how you used the service and what you felt was lacking that can be solved with new technologies.

2. Spot something difficult to use, make it easier.

Whenever you see products/services that are difficult to use, your job is to make it easier for everyone to use. Think about how difficult it was to create your own virtual machine. Thanks to Amazon, it's now a few mouse clicks away. It's not creating something brand new, but providing existing services in a way that is easy for everyone to use. User experience design is the product.

3. Look for instances where users are not the beneficiaries.

There are many instances where users are not the ones stand to gain from using the product. Often there are multiple parties involved in using the service. Think of how kids want to surf the web and how parents would like to control what activities the kids are allowed to do. Because there are two or more parties using the system, there are often unmet needs from multiple user groups. There are also finer social nuance to think about when designing a product for multiple users.

I would love to know if you have any other angle that you use to look for a problem. Any other angles to add?

Excerpts from Fresh Air interview with Frank Langella

2013-03-31T22:49:00.002-07:00

Frank Langella gave an interview at Fresh Air from WHYY August 2012. It happened to be on the radio the other day, and I was fortunate to catch the tail end of the interview. I found Langella's interview to be very moving. I had to go back and listen to the whole interview.

Before listening to the interview I was not familiar with Langella's work. I found out that he starred in Robot & Frank, Frost/Nixon and other films.

Instead of paraphrasing his comments, I want to share his quotes talking about how he learned to be more tactful in sharing his views with others, and how transient everything that we once claimed as ours. I just cannot help but be humbled by this 75-year-old man reminding us that we are all passing through our lives.

Following is the excerpts from Frank Langella's interview with Fresh Air:

"Yes, I was. I made the mistake of believing - as so many young actors do, and many young men do, and women too, I suppose - that because you feel you're right about something it gives you the right to behave badly, or stubbornly or arrogantly to make your point. I think it's a function of youth and I give a wide birth to young actors who are like that these days. The notion that what you feel is the right way to do something or how to do it is the correct way, can make you walk around with blinders on and give you very little understanding into the feelings of the person opposite you, who has their own point of view and their own way of expressing themselves. And so I was, I was a very forceful young man, very strong minded and very strong-willed, and I've moderated that over the years a great deal. I'm not entirely free of it, but I'm still strong minded, but I think I'm a lot more tactful about it now than I used to be."

-----

"Yeah. I like very much the story of an actor that nobody remembers anymore called Cameron Mitchell. I made a television film with him and we discovered halfway through the making of the movie that I was wearing a jacket that he had worn when he was a young leading man some 25 years before in a major movie. And now he was doing a terrible television show.

And the story is longer than this, but the makeup lady, the costume lady, picked it up off my chair and said, Cameron, look at this. Frank is wearing a jacket with your name sewed into it from a movie of 25 years ago. And Cameron was now an overweight, I'm afraid, heavy drinking actor who had really rolled, sadly, to the bottom.

And she pushed the jacket onto him and it didn't fit him. It was three sizes too small for him. So he started dancing around kind of like a silly clown and I could see in his face that he was in agony about this; that his youth was gone, his career had fallen apart, and I felt a tremendous wave of compassion for him.

And everybody else thought it was funny. And I just walked up to him and told him I needed the jacket for the next shot and I took it from him and put it on. And when his name came up in the memoriam section at the Academy Awards that year that he died, a number of years later, there was a little spattering of applause.

And somebody else's name came up and they got a bigger hand and somebody got nothing, and even in death there was this rating system to the performer. And what I wrote was that it was a room full of people at the Oscars believing that whatever jacket or dress or gown or tuxedo they were wearing that night was going to fit them forever. And I think that that's the one that resonates with me most because I think it's true of a lot of us.

You know, we kind of believe at the top of our game that it's always going to be like this. And we have to keep reminding ourselves that it isn't, for better or worse. Sometimes it gets much better. Like this is the best time of my life. But it can get terribly sad for people who keep trying to hold onto the thing they were initially loved for. So that - that story means a lot to me."

You can hear the full interview with Frank Langella at this Fresh Air page.

Chris McCann: StartupDigest and GroupTie

2013-03-30T23:04:00.002-07:00

Chris McCann is a serial entrepreneur who started StartupDigest and GroupTie. He started StartupDigest soon after he packed all his belongings in his car and drove to Palo Alto without a place to stay. StartupDigest is a free weekly email digest outlining the startup events and resources in hundreds of cities around the world.

He has been running his personal blog since 2009, and here are some blog entries that I found interesting:

He also spoke at SVC2Baltics last December.

When I first jumped into startup scene back in 2000, I did not have any of these resources that new entrepreneurs have. There may be communities and resources around, but I did not think that I needed to worry about distribution or how to get traction with customers. All I was focusing on was how to get my code to run more efficiently and come up with automated way of solving complex problems.

Now that I look back, I realize how much blinder I had on. Thinking about customers and how customers will be solving their problems with our solution did not enter my mind. But in reality that's the number one thing that mattered.

Today starting up a new business and becoming entrepreneurs makes more sense than ever. I think this trend will continue. As more people share about their startup stories and how to create a sustainable business doing the things they like doing, I am convinced that the overall economy will transform. In that economy of future, creativity, persistence and collaboration will be the key to success, not just following directions and repeating what's already been done.

Email as messaging system

2013-03-29T18:38:00.001-07:00

I ran into Sachin Agarwal's blog about how email is the de-facto standard messaging system of Internet. I totally agree. Email is a very simple tool that everyone understands. Although I hate using email as collaboration tool, email has its killer use case, and it is here to stay.

I can think of the following compelling reasons why email is not going away.

1. Email has a very powerful analogy in real world: snail mail that you get in your mailbox.

Everyone understands email. Even to someone who has never been on the internet (it's hard to imagine, but try...), we have a simple analogy to explain what email is. It's a mail sent and received electronically from computer to computer. It works just like mail. You write a message, write the recipient's address, and click send. It gets magically delivered to the recipient. Just like a mail, without the hassle of worrying about stamp.

2. Email was the first messaging application created at the beginning of Internet that spans the entire net.

One of the first thing that people thought of when they created network of computers was to write email application. Sending and receiving messages was something that everyone wanted to do. These days everyone on Internet has one or more email addresses. It's available to everyone on Internet regardless of which ISP, country, device and internet connectivity. It's a truly universal communication channel.

3. Email is free.

Thanks to free webmail sites, email is free to everyone who has access to Internet. If you have access to internet, anyone can create an email account. Not only that sending email is free. Sender does not have to worry about stamps.

4. It is personal and private.

Email is inherently personal and private because it is sent by you to a clear set of recipients. Although there have been explosion of social media, the need to communicate with people personally and privately remains.

For any application, there is a need to communicate with end users. Despite Facebook and Twitter accounts, the reason why email is important is because of the above reasons. When a service needs to reach all its users in personal and private manner without having to worry about how the users will consume the message, it must be the email.

Pebble watch, first impression

2013-03-28T23:06:00.000-07:00

I finally received my Pebble watch yesterday. I backed the Pebble project on Kickstarter last April. Originally Pebble team projected their ship date to be somewhere in September, but it got shifted out indefinitely as the team tried to figure out how to deal with massive number of orders through Kickstarter. I got the news that the watches were getting shipped starting January.

The packaging reminded me of Amazon Kindle packaging. It was made with 100% recyclable material. Inside the recyclable box, it had two simple pieces. One Pebble watch and one USB charger cable.

The setup process was simple. Download the Pebble app, do software update, and pair the Pebble with my smartphone. Then it was set.

I didn't know what to do next. When I got done playing around with watch faces, I had to remind myself that my Pebble was connected with my phone. Yes, the whole point of Pebble watch was that the watch could be used as an extension of my phone display.

Two applications that shipped with the watch were music controller and text message display. Music controller worked as expected. It allowed play/pause and forward/rewind of whatever that is being played. There weren't any surprise with text message either. It displayed the text message with vibration as soon as my phone received the message.

Overall, my Pebble watch worked quite well. Starting from packaging to setup and build quality, I think the Pebble team did a good job delivering on their promises. Yet, I feel that the killer app is yet to be built.

Controlling music and receiving text messages are good start. But they both require taking the phone out to plug in your earphone and sending the text to reply. I think the killer application is an alerting app based on location. Imagine as you move around throughout your day, your Pebble watch alerting you of key information that you might find useful depending on where you are. Say if you are at the airport for connecting flight. Your phone figures out the next flight, lets you know that how much time you have until the connecting flight, and gives you direction to the gate.

Many tech giants are already talking about applications like that. Google is working on its Google Glass, and it has already released Google Now providing users with location-relevant updates. Apple and Samsung are working on smart watches that can be used as hyper portable and personal tiny screen for timely updates.

Pebble is a harbinger to next wave of portable connected devices. And it is a solid one at that.

A conversation about startup

2013-03-27T19:17:00.002-07:00

A: Hey, long time no see!

B: Yeah, it's been a long time. How have you been?

A: Slogging through. Still in the middle of startup phase.

B: Startup? I thought you are well passed that stage. I don't think anyone would consider your company as a startup.

A: Perhaps. There are just lot going on, you know. Hiring, getting new people up to speed, working out team dynamics, etc.

B: Sure, but that's not a startup-only challenge. That is true for any growing company.

A: Yeah... I am with you on that. What would you call startup? What makes a company startup?

B: For one thing, if it is a brand new, then obviously it's a startup. Once someone told me that startup is a phase when money is invested for future revenue. Basically, burning cash. But that can't be it because my earlier startup we started making money about a month in. It was small, but we were making money right away.

A: Positive cash flow right away. That is the ideal model for self-funded bootstrapping.

B: Look, I have to run. Have a meeting starting in a few minutes.

What does make a startup a startup?

I think it has more to do with risk tolerance and upside potential compared to current valuation. Startup has a mindset that there is something to prove with their idea, investment and the team. They are there to prove that they have what it takes to build a business and change the world. They don't think about protecting their wealth. They are out there to build something new.

And they are able to do this because there is everything to be gained by building something awesome from their blood, sweat and tears.

If there is no such mindset, I wouldn't call it a startup.

Innovation comes from fuller understanding of the problem

2013-03-26T23:21:00.001-07:00

I am still ruminating on sessions that I attended during Silicon Valley Product Camp 2013. One remark someone made about innovation is circling around me.

Innovation comes from fuller understanding of the problem.

I don't recall who exactly said it. Whether it was Steve Johnson or someone in the audience, I cannot quite remember. Yet I think it captures the one aspect of how innovation happens. That is, thinking about the problem and understanding the constraints under which a new solution needs to be proposed.

In its simplest sense, we have to understand the problem before we can come up with creative solutions that solves the problem.

This was the example that Steve Johnson gave.

Problem: I want to adjust the temperature in the room.

As one line problem, there are lots of solutions. If we google for thermostat, we can see many solutions to this problem. All of them let you set the temperature in one way or another. Problem solved.

9 buttons and 3 temperature numbers.
You'd better have kept the manual handy.
Source: http://www.aaaheatingac.com/

But the real-world problem goes beyond what is captured in that one line.

Real-world problem: I want to adjust the temperature easily. I may also want to conserve energy while doing it.

Now that's a more realistic problem. Real problems tend to be complex. It has many layers of constraints under which it needs to be solved.

People don't just care about setting the temperature. They also want to do it without having to look up the manual to figure out how. They prefer easy and elegant design over complex and crude design. If possible, they just want the thermostat to figure out what comfortable room temperature should be given how earlier temperature settings were. When people are traveling, turning itself off to save energy would be a big plus. It would also be cool (pun intended) to be able to turn on A/C as you head home using your smartphone.

Reaching fuller understanding of the problem is about understanding the little details about what users are looking to solve, and coming up with a solution for each detail. Only when the entire problem is understood, then the innovation can happen solving as much problem areas as it can.

No manual needed. Just dial to set the temperature.
It also comes with iPhone app and learns your temperature preferences.
Source: http://firewireblog.com/

Johnson mentioned Nest thermostat as solving all of the little problems above. His experience of using it delighted him enough to use it as his example of what to imitate. By solving not only the simple task of setting the temperature but also lots of other related problems, Nest thermostat was able to make a fan out of Johnson.

From Nest's perspective, solving the simple problem would have created MVP of thermostat. But there are dozens of thermostats like that. What was missing from the thermostat market, and the reason why it felt so innovative was because Nest solved the entire problem.

When trying to be more innovative, first understand the fuller problem with all of its details. MVP does not need to include all features for a very good reason. But in order to be an innovative product, someone must think hard about what other components of solutions can be added to MVP and in what order.

Do you have any other example of fuller understanding of the problem leading to innovative product design?

Ask why?

2013-03-25T22:30:00.002-07:00

I once remember reading that Toyota had this process called 5 Whys. Whenever a process fails or they encountered a problem, they would ask why the failure occurred. When they find the answer, then they would ask why again to figure out the reason for the answer being the way it was. The would repeat this asking whys 5 times for each failure. Only after understanding the five-levels of why, they would make changes to prevent the root cause from happening again.

I believe that asking why is an important step in understanding the entire problem domain. Without understanding the real problem, we end up treating the symptoms. When the band aid wears off, it soon happens again, and we would have to fix it all over again.

In order to be able to ask why, everyone needs to clearly understand the objective for each step and the reasons why the decisions were made the way they were. But that's not always easy. Team members may be geographically distributed, each member can have different perspective from each other, hence may see things from a different angle. Combine them with aggressive schedule, team members may feel that their primary job of writing functional code is all that matters, and do not take time to ask whys.

Let's apply the five-levels of why to the problem of people not asking why for a fictitious organization, ACME corp:

People don't ask why because they are rewarded for short-term results rather than long-term results.
People are rewarded for short-term results because ultimate metric is each quarter's revenue number.
Main metric is quarterly revenue number because there is no long-term commitment.
Lack of long-term commitment is because people are not sure whether they will be around to see the benefit.
People are not sure because they are not fully committed to the organization.

So to fix this problem for ACME corp, we need to do the following:

Create meaningful metrics that measures the longer-term results.
Reward them based on longer-term metrics.
Engender employee loyalty by aligning company values with employee's common values.
Hire employees with longer-term commitment to the company, and incentivize them to stay longer.

These solutions are not obvious when we focus on the first-order problem. We have to drill down to figure out what is causing the problem.

See if you can apply to your problem and come up with suggested action items to improve the situation.