Leon Ho

Founder of Lifehack and Steply.
Reach me leon [at] leonho.com.
~ Tuesday, August 14 ~
Permalink

Become a passionately curious person

image

I have no special talent. I am only passionately curious. — Albert Einstein

There are three types of people:

  • Those who do not ask enough questions.
  • Have a lot of questions but no intention to answer them.
  • Ask good questions and seek ways to answer them.
Without questions, we accept the way things are without understanding the cause and effects of how things behave. Without the answers, we will never know if our assumptions are true and if the product is heading in the right direction.

Let’s take our fashion app, Chaopin, as an example. We initially assumed that females love to buy fashion related stuff, so we steered our content towards females. However, we tested this assumption and it was proven wrong. Even though we have less male fashion items in our feeds and fashion catalogs, over 90% of purchases were from males.

This was a big surprise to us and we wondered why.

Out of curiosity and to learn, we kept digging into questions such as:

  • Are males or females buying male items?
  • Why are there still many female items on the hot fashion item feeds when most of the items purchased are male items?
  • Is there a difference between male and female users behavior? If so, what?
  • What happen if we decrease the number of female items and increase male items?
  • What factors are there in the market that contributes to this behavior?

Eventually, we created many more questions and prioritized them. Some were eliminated but many needed to be answered through metrics and user feedback. This helps to drive actions that lead to a better targeted product and saves us working on ideas that may be based on faulty assumptions.

With all these questions, we didn’t stop there. We were eager to learn so we came up with metrics that we previously wouldn’t have thought useful, discussed different possibilities and tried to prove them true or false. In the process we gained important knowledge and helped us to understand how people use Chaopin and how we tailor the app to address the need of the market.

This process also helped us to develop a skill in asking better questions. The more questions that were asked, the more insightful our questions were.

As Albert Einstein put — become passionately curious is extremely useful. Curiosity will lead you to ask and answer many questions, and with a good framework you can gain important insights from a few crucial questions.

You won’t go far if learning isn’t your first priority when developing a product. You will run around in circles if you don’t have curiosity.

Tags: curiosity product management answer learning
~ Tuesday, March 27 ~
Permalink

Doing is better than thinking

Photo credit: dlr_de (CC BY-NC-ND 2.0)

Some entrepreneurs wait and wait for their “best idea” before starting. They have many ideas that they never execute because  they have a fear that they will be beaten by competitors. They have a fear of failure and this is the main reason some people never even start on the ‘entrepreneur’ path. They fail to break startup inertia.

Stories like Google and Facebook give false hope. It may sound like every successful entrepreneur got their first venture right and became super successful and that’s part of the reason why people want to find the “perfect” idea before investing their time on it. But this is the exception rather than the rule.

Instead I prefer stories which fit into the real world more, such as Angry Birds or Draw Something. If you don’t know their stories, Angry Birds was Rovio’s 52nd game, and OMGPOP spent 6 years to develop 35 games before releasing Draw Something on iOS and sold it for USD$180M.

Why is this more realistic? People need learning to build their experience and experience is more likely to lead to success.

Isn’t learning from other entrepreneur’s experience quicker? No, you can only obtain a tiny chunk of experience from other entrepreneurs in their sharing. The only way to learn every aspects of entrepreneurship is by doing. When you know what you lack, then you can ask the right questions to speed up your learning process.

Often the initial idea is crappy. You have to get your hands dirty before finding the right path for your product. For instance, our team wouldn’t have developed the Darkroom app as a Christmas project (which pivoted to the idea of the photo app network called Steply that attracts 9M+ downloads) if we didn’t develop a few unsuccessful productivity apps for iPhone. Without our experience in Steply, we wouldn’t be working on Chaopin, a fashion photo app, that attracts million of photo views every month. Once you get started, moving in momentum is much easier than the initial launch.

Don’t just think. Start by doing.

Tags: development experience pivot startup Zero
~ Tuesday, January 10 ~
Permalink

Never let your product become a half-assed product


Photo credit: tambako (CC BY-SA 2.0)

You have a product, and there are dozens of features you want to add. It always sounds like you need everything in order to win your customers over.

In reality? Features are never felt enough by you and your customers.

No matter how big your team is, your resources and focus are always in constraint. If you only have few features, you can focus and make it as polished and well presented as possible; If you have dozens of features, the time you can spend on each feature will be much limited. If you can’t manage all these efforts, your product will become a half-assed product.

Take Twitter for example, how many core features do they have? And yet they have became one of the biggest social networks.

Don’t argue with me that you need to make your product unpolished because you are aiming for a minimum viable product (MVP). MVP does not mean a half-assed product, period. Your MVP is a set assumptions you made on the product that potentially wins your potential customers attention and engage with you. It doesn’t mean to cut corners. If you don’t have enough time to work on a real functional product, can your MVP be a mockup version of your solution that you can show to customers instead? 

Cut nice-to-have features. Improve must-have features that solve real problems. Writers trim paragraphs to make a good article. Directors remove scenes to make an awesome movie. As an entrepreneur, you need to edit your product in order to make your product fantastic.

Tags: development feature mvp pm product Iteration
236 notes
~ Monday, November 14 ~
Permalink

Thirteen FAQs to simplify and speed up your startup project


Photo credit: dkalo (CC BY-SA 2.0)

Greg and I were talking on the other day about how we usually review an idea. It could be a feature implementation, a bug fix, or an UI improvement. When the idea is generated by ourselves, our team, or customers, we tend to ask some questions to validate the idea, other question are here to simplify the solution and clarify some technical details:

  1. What assumptions we are making here?
    Are there too many assumptions that make this task a high risk? Even if it doesn’t work do we know which assumption is wrong? Are there any assumptions we made that we didn’t realized? What do we measure to test the assumptions and what can we learn from the results of the test?
     
  2. What is the single biggest pain point we are trying to solve?
    Are we spending time to solve a problem? Is it worth solving? Is it really the biggest problem, or are we addressing a symptom and not the cause?
     
  3. Does it improve our metrics or contribute to growth?
    Everything should improve our goals which are tracked using some measurements. If it is just apple polishing but not moving the needle towards the target, why bother?
     
  4. If we do this, who benefits and how?
    Are we providing a solution for our targeted users (or segment of our users) needs?
     
  5. If we don’t do this, who get hurt and how?
    This may be more important than the previous question. Sometimes users are suffering with the existing product. The faster we solve it, the happier they are.
     
  6. Is there a faster way of doing this?
    Have we thought of all options? Is there a simpler and maintainable way to implement this? 
     
  7. If we don’t have enough data to make this decision, how can we gather the data?
    Let’s think of more paths to research. What is preventing us from getting the data we need and how can we get around this data block? Are there complementary data points where we can extrapolate data to help us with a guided decision. Not everything can be exact, but we should try to gather enough information so that we can make an informed decision rather than guessing.
     
  8. Now we know the pros. What are the cons?
    When we want something to get implemented, we always thought about the benefits we gain from doing it. Keep in mind that everything has negatives too. To make a objective decision, we need to know the CONs too to be able to make the right decision.
     
  9. Can we make this in N weeks iteration? What do we need to cut to achieve that?
    Can we make this in time? Time constraint encourages creativity, when time is a factor in analysis, it can lead to thinking up alternatives that would not normally be considered. Can we do less but achieve the same objective? A long interation cycle can result in the same end product as a short iteration cycle, except with more polish that doesn’t help move the needloe towards the goal. 
     
  10. Can this architecture be simplified and extended later when needed?
    Often we may over-architect to accommodate something that may not be used in the future. This is potential wastage. There is no point in investing into something now which could be delayed until the future, or not even used. It means it is possible to release sooner, smaller and lighter.

  11. Can we avoid this code/automation and test the solution manually with human?
    As an engineer, we always think programmatically and believe automation is always faster than doing it manually. But what happen if the solution is not applicable before we can cover the cost? It may be more cost effective and time effective to test manually rather than spending the time and resources to create an automated test solution. Will creating the automation test cause a delay in releasing? Will it move resources away from developing the core product?  It maybe faster to run manual tests over several releases before an automated solution is ready, even then, the product may already have evolved past the point of the usefulness of the automated tool.
     
  12. What’s your time estimation?
    Have you thought out the scope of implementation? Do have an idea about how long it will take and can it fit into the timescale of this iteration cycle?  

  13. Anything more we can remove from this iteration?
    Are we adding something unimportant?  Unimportant is anything that doesn’t help to move that needle!

What are your FAQs?

Tags: design engineering faq pm startup team Develop
31 notes
~ Monday, October 24 ~
Permalink

Empathy is a powerful tool for startup


Photo credit: RishiB (CC BY-NC-ND 2.0)

I started my career as a programmer but I am lucky enough to learn and work on UI/UX in my startup. I asked some of my designer friends: What is the most important aspect of designing a product? They told me it’s empathy. Without understanding users pain and needs, you can never design a usable interface.

Empathy is not only a powerful capacity for design, it is also an amazing ability for anything that is related to human interaction.

Recently when our team were drafting an email to potential customers, we wrote it in a way  that is just stating the facts of our beta product. It’s a very clear and straightforward email, but it’s not something people would respond and act on. Then we thought about the recipients’ background, their needs, and their views on our product externally, we figured out we did not set the right tone to give them the confidence they need.

It sounds easy, but human beings tend to have a blind spot for recognizing issues from other people’s perspective and only see it from our own view. Learning the ability to detach from our own views and assumptions and putting yourself in someone else’s shoes is a very important ability.

Another situation is when we talked with potential partners and tried to understand their needs. It’s difficult because you need to convince yourself, as well as to convince them, because potential partners usually want your product to behave in ways which may not be in the same direction as yours. As the creator of the product, you wouldn’t want to see your product diverge into something that is tailor made for one person. From the other side of the fence, they want a custom-made product that fits their needs. Trying to empathize with their real requirements on the partnership and then figure out the balanced way to fit your vision to their needs should be your number one goal.

Sometimes you could be right but your customers may not see it. In  the Steply network, our users care a lot if other users are cheating by uploading someone elses photos. We realized this problem. We spot any irregularity and get reports from users in order to moderate it and give out warnings to users in question, even though users assumed we have done nothing to prevent it. This is certainly a discouragement, but looking from their angle, they may not recognize our efforts from what they see. 

Empathy gives you the reasoning, the information, and sometimes reduces the negativity and lets you get a glimpse of the whole story. Without empathy, you may create a product that no one wants, a business proposal that no one agrees with, or assess a situation that looks pretty different from the actual truth.

Tags: design partnership startup customer
12 notes
~ Sunday, September 25 ~
Permalink

7 ideas on how to hire a great programmer

The tech job market is crowded. So crowded that it can be difficult to find and hire great people that care about the work that they do especially when you are a small startup. This is especially true for programmers where their resume may not exactly match up with their actual talent.

A lot of hackers can say on their resume that they have programmed with ‘X’ framework for 5 years and have worked on ‘Y’ project that saved a startup ‘Z’ millions of dollars. But what a piece of paper cannot show is just how much drive, smarts, talent, and zeal that said hacker actually has.

Because of that it is important to dive a little deeper when one is looking to hire great developer. Some ideas to consider are as follows:

Do they really like programming?

It is a good thing to look at a developer’s sample code from past assignments, especially things that they have worked on in their spare time.

You and I may think that if you don’t like to do something you should not make a career of it. But that is not the case for many people. There are many young people that go to college and think that if they major in something that they will make big money, not caring at all what the work will entail. Make sure that the candidate really likes programming. Even loves programming and considers themselves a bona fide hacker. If they get up in the morning thinking about a new design they want to try or have figured out a problem in their sleep, this is the person with passion and drive that you want to hire.

Always ask for sample code

Throughout the searching and interview process there are some things about the prospective developer’s personality that you can take note of:

Look at the organization of their code. Is it clear? Well documented? Not overly documented? Does the code use some advanced ideas and represent a decent design?

Also, ask what the hardest part of her code was to overcome. Can she speak clearly about the problem and explain to you how she solved it?

Another word of caution; if she cannot provide sample code or her sample code is horrid, then this person is not the great one that you are looking for.

Look for general attributes that a hacker should have

  1. Can they learn quickly and efficiently?
  2. Check their personality. Is this someone that you could work with on a team for hours a day?
  3. Do they ask many question about your product? Do they actually seem interested in what you are offering?
  4. Make sure their attitude is that of someone that wants to learn, not overly confident and acting as if they know everything about programming and various technologies.

Ask difficult technical questions

Not only will asking the potential developer about difficult concepts such as the point of polymorphism, interfaces, threading and design patterns inform you whether or not she knows what she is talking about, it will also show you what she is generally interested in the technology realm. Not every great programmer is going to know very difficult concepts regarding programming languages and software development, but asking them to discuss these ideas will let you know where they stand, what their strengths and weaknesses are, and what they are interested in as a developer.

Major and GPA is insignificant

I’ve met many great developerss who have not majored in Computer Science or a related field. Having a degree in a technical field is an added bonus, but it does not make a great programmer.

Understand them as a developer and a person

Has the candidate had a solid streak of being able to get things done on time? Even under pressure? How do they handle stress and how do they manage themselves to push out many productive hours of developing? Even with difficult questions and problems, are they persistent enough to follow through and solve them?

Probably the most important thing that you can use to judge if someone is great at programming other than them being passionate and smart is assessing their drive. Drive is a an amazing thing. It will take someone who is of mediocre to good talent and push them over the edge of becoming a great, pragmatic programmer.

Follow up and test them

Large software development companies are looking for excellent engineers and to do so they tend to give them problems to take home and solve through programming. This is a great way to understand how the potential developer works and how well they can solve problems.

The programming assignment does not even have to be difficult. In fact, if you really want to weed out average hackers, give them a simple assignment and take a look at their code. Is there duplicate logic? Certain lines that can be totally omitted? If you see this type of code then you can guarantee that the programmer is not on her “A” game.

Also, if you want to give them a larger test you could potentially hire them for freelance work on a small project and see how they pan out. This can sometimes be an expensive thing to do, but if you have a feeling that they are someone you want in the first place, it can’t hurt to have them do a little paid work for you to see how they fit.

It’s important to get it right

Hiring a great programmer takes time and experience to do. It’s easy to get caught up in their skills and experience list, but if they don’t have the correct hacker mindset and attitude, they may be the completely wrong person.

There are many developers out their that like to code and do a good job of it. But there is a much smaller percentage that live and breath software development, beautiful code, and have the drive to solve difficult and interesting problems. Finding these type of hackers is worth the extra effort and time as they produce the best results for your startup while they are being fulfilled intellectually.

Tags: startup hiring programmer
31 notes