Leon Ho

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?

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.