1..2..3.. just ship it!

Shut up and listen

2013-07-14T11:07:00.000-07:00

I always had a problem with listening to people.

There was so many awesome things I wanted to share in a conversation. Instead of listening, I was thinking about the next thing I could say. Last thing I cared about is whether it is as interesting to others as it is to me.

It caused a lot of problems. There was a girl called Mary that I knew very well, but we haven't talk for a while. We met on a party and had a small chat. Bla bla bla things were going all right until I changed subject to my AWESOME projects I was working on. Soon I found myself standing alone with a beer while she found an excuse to go away. Why? As it turned out, she got fired few days earlier. Me talking about my awesome work was the last thing she wanted to hear about.

"How to become great conversontialist? The secret lies in being a great listener. Listening builds trust and belief." said Dale Carnegie in "How to win friends and influence people" and he was damn right. Everyone cares about themselves (just as I did), not about you or your stories.

Empathy

Few years, tons of books and 2 startups later I am sure that listening is one of the most important skills. Not only to have someone to drink beer with, but in entrepreneurship as well.

The story of Mary is what we often do with ours customers: "Hey, I heard that you suck at this. That's great because I'm awesome and you could gain so MUCH with me. Let's talk about me a little more".

Would you like to hear about someone awesomeness when you have a problem? Not at all. But you probably would like to hear that someone understands your problems or has been in your place many times. That's empathy, being able to feel what other person feels.

Shut up and listen

But it's not so simple to be empathical, especially when you are not sure about their problems and worldviews. Hopefully, you have a powerful weapon to achieve that: shutting up. Everyone talks about talking to your customers. Don't talk, because you will probably talk about yourself. Just sit and listen, don't interrupt. Encourage others to talk about things they want to say and learn.

"Don't find customers for your product, find products for your consumers" - Seth Godin

Lesson learned

Knowing your customers is one of the essentials of successful business. So instead of veryfing my assumptions, at first I don't make any assuptions at all. I try to act like a hidden cameramen from national geographic and observe my target audience:

Go on a meetup and listen what they say about certain topics.
Find a discussion board and read. I don't egage in any discussion, just observe and investigate. Here's how I investigated Hackernews and Reddit.
Make notes about patterns: worldviews and pains that repeats. Imagine it like an investigation board from criminal movies.

Why is it so essential to know your customer?

The best birthday presents are the ones showing your care about a person or knowledge about his likes and passions. Without such a knowledge at most you can buy a bottle of good vine, which is also fine but won't make anybody cry from happiness.

Finding a problem and good solution is only a tip of an iceberg. You have to build trust between you and your customer. You have to know where and how to approach him. You have to sell the solution. You have to create something that feels especially for him. To achieve that you can either make a long shot based on your assumptions or get to know him better.

Demographic data are useless for a startup

2013-07-03T11:46:00.000-07:00

It is said that at the beginning of a startup/product journey you should focus on your perfect customer. What seems to be a problem is who to choose and how to define them.

Definitely you shouldn't focus on demographics, social profile, place of living etc. (unless you are working on a new type of washing powder). The internet changed the old ways of marketing.

What we are looking for is a tribe - a group of people that will admit they are a part of a certain community. Imagine if somebody asked you to tell who you are or what you do. You wouldn't say that you are 30 years old white male with average income, living in a big city.

What would you say instead? Young dad, web developer, skateboarder, star wars fan, startups enthusiast, DIY etc. People identify themselves with family situation, hobby, interests, place of work etc. When you identify with a group, you share a lot of similiar worldviews - and this is what we are looking for. Worldviews are lethal weapon when it comes to marketing - you can say something that you know your audience will agree with.

What are a tribe's characteristics?

They share certain things with other members: jargon, worldviews, interests, pains, problems.
They have a place / places where they meet and discuss 'tribe's stuff' - on groups, mailing lists, discussion boards. For example hackernews is a place where at least three tribes meet: startup founders, developers, designers.
They have events / meetups / conferences where they meet
They feel some kind of a bond with each other

Now you probably see how much easier will it be to start marketing a product when you have a tribe to target. Use their language in marketing materials. Write something that you know they agree with. Read their discussion board to find prospects and get to know them better. Go on a meetup and talk to your future customers.

Common mistakes in choosing a target audience:

You have to like your tribe in order to emphasize with them. When you hate the corporation culture, don't even think about making a startup for a large companies. You'll spend next five years of your live working on a project you don't like
Tech SMB is not a tribe. But tribes are: marketing managers in Tech SMB, owners of SMB, CTOs of SMB. You are targeting a group of people, not an institution
If you think that your tribe is too big for a start, try to narrow it by demographics or characteristics (social marketing managers instead of marketing managers)

It's the same story with segmenting your actual client base. Divide them by tribes, not by demographics and your marketing efforts will be far more effective, focused on a solid niche.

Have you run out of ideas how to attract customers? If yes, you should click this button.

Reinventing the startup

2013-04-11T01:28:00.000-07:00

I just spent first day of two-weeks session with guys from keepone.com working on their very first pivot.

Why to pivot?

Keepone is a product built within the last four months by a team of 7. The base idea was to create a social bookmarking place where users can build their own private or public collections from all the things they can find on the internet: pics, movies, articles, files. It should be like a mix of pinterest and dropbox. As you can realize the niche here is very crowded and it's really hard to stand out.

Product was built in a "stealth mode" and just after the first release there happens not to be any traction (surprisingly there was no "wow" factor and tons of users right from the start). The team realized the mistakes they made and we had to go back to base assumptions in order to plan a pivot.

How to pivot?

We decided to take a huge step back to the beggining of a startup's work and implementation of a lean startup methodology principles.

Plan is simple:

retrospect what was good, bad and what mistakes happened during the last 4 months

choose concrete actions about it

forget for a moment about the whole product

choose and fully focus on a narrow target group

research & QA in order to define the profile of a group and find the biggest pain points

prepare and test as many hypothesis about probable fixes to their pains

use lean methodology to iterate and verify hypothesis without creating any application

prepare an MVP of a new product or plan modifications to actual one

We give ourselves two weeks to do so. And here is what we accomplished in a day one:

Retrospection

The purpose here was to do some cleaning and talk about all the smells? that happened. Then figure out why we ended in this place and how we could avoid it. Also we suppose to gather good things that happened, but as it always turned out, everyone focused on the negatives :)

Most important things we've learned:

There was too wide target audience chose

Idea was based on a lot of unverified assumptions

There was a moment when team stopped to belive in the idea

Problems with communication inside the team (not clear?

The market research wasn't conducted properly (and because of that, competitors were underestimated)

Stealth mode without verification of any features

Implementation process was working fine (as always the technology and implementation is the smallest problem)

The first thing we decided to do is to focus on a narrow target group. In order to do so, I've invented a little game.

Choosing a narrow target group

This is an easy thing to say, but really hard to implement. There is an easy way to choose your niche, but you have to forget about demographics. What you need to find is a tribe, a community. People from your target group have to feel like they are part of it.

Example: you'll admit that you're in a developer community but you'll never say that you're 20-30 years old single from a big city. Being a developer means that you have certain needs, problems, habits and worldviews, being a single doesn't mean anything that is useful for your business.

Ask yourself a question what are the niches you are a part of. Skateboarders, startupers, entrepreneurs, managers, geeks, salesman's electronic music fans and so on. This will help you figure out where to look for.
We did so.. we created a list of target audiences and put it in order by how much we like them and how good they look like for us.
We narrowed from 30 groups to 5 most promising:

video bloggers

game bloggers

hipsters, appleboys, geeks, gadgets lovers

freelancers

Do It Yourself niche

As you can see we've focused on content creators as most promising group for us. The next step is to divide them into smaller chunks and end up with really narrow groups. Than eventually get to know their problems. To do so we started the research in a methodology called "safari" which I will describe next time.

What HN and Reddit think about startups

2013-04-03T02:52:00.000-07:00

There are a lot of misconceptions about startups that every entrepreneur discover sooner or later. One of them is that you have to learn from your own mistakes. I know that a lot of them are questionable and subjective, but I was curious how many of them are "startup truths" to which almost every experienced entrepreneur agrees.

In order to do so I couldn't base my assumptions on my own experience because... well they are only assumptions. There are tons of articles like 'things I've learned about startups'. Some of the points repeat, but most of them are just subjective, controversial opinions.

I needed raw, statistical data. But where to look for such a data?

HN and reddit's r/startups are two places where community is strong and where real discussion happens. The best thing is that you can immediately know when community agrees on something thanks to points/upvotes people give you.

The articles are just themes that help to fire up a discussion about certain topic. I decided to focus on comments, not on sources and I started to dig.

What I basically did:

searched for themes that repeated often on HN/reddit (like fails, startup ideas, creating a mvp)
gathered all the world views about certain theme
choosed all the world views that are repeated or were voted high, neglected controversial ones

No subjective opinions, no 'my experience' thoughts, just raw statistical data. I am in the middle of a reasearch (it's boring and takes time) though I wanted to share with you some results in order to verify if my methodology works. Sit tight and tell me how many times did you nod your head.

Failures

Failure is a part of entrepreneurship. Most startups will fail few times before they learn how to fulfill market needs

Fails are devastating. You invested so much in following your idea that every, even small change feels like tearing your heart apart

Successes are exceptions. There's much more probability that your startup idea won't work and it's only up to you how fast will you verify it

Fear of failure often stops you from realeasing your project and validating it. Just accept the risk of not matching your customer needs, implementing another feature won't reduce it

In order to lower the probability of a failure, take small, measured risks and verify every hypothesis.

Startup Ideas

Execution is 99% of a startup success. Facebook and Amazon are good ideas with brilliant execution. Ideas are just multipliers of an execution: (brilliant idea) x (crappy execution) = still zero

Ideas have to be verified ASAP. Your assumptions are probably wrong."I think my idea is brilliant and so will everybody else"

Ideas can be verified without even building an MVP through customer interviews, gathering data, attracting the customers with your pitch and so on.

Stealth mode is a bad idea. 99% of ideas are not worth stealing, some should be protected but probably not yours.

Stealth mode often drives "fear of launch" sickness. "Only one last feature and we are launching" - yeah, right.

People are rarely objective when it comes to their idea. Every founder believes that his idea has a great potential. That is why others' opinion (customers, advisors) is so important

Founders are not honest with themselves about expected failure rate when the realistic probablility for success is very low. Verify 'how are you doing' on numbers and key success factors, it'll help you be more realistic

MVP and prototypes

Successful app is as much about what it doesn't do as what it does. A lot of features you build will be not used. That is why it is so important to start from minimal viable product - simplicity is the key

Test the performance of every new feature you build. Even if users requested for it, they may not need it.. and remember, every new feature makes product a little more complex

It's hard to evaluate whether you are producing useful MVP. What can help you is questioning every feature and keeping it as simple as possible.

Don't listen to your users when it comes to building a product. Users are not good product builders. Rather than that, gather data.

Execution

Startups are not only magical adventure. There is a lot of administrative tasks and paperwork. It's tough and it's boring and you have to do it. Often there is more paperwork than adventure.

Doing a startup is all about balancing: design, development, sales, marketing, optimizing, testing. Don't lock yourself in a comfort zone and try not to neglect any of those - learn

You'll never know how good your product is until people touch it. Ship often and fast.

In order to ship effectively, break big and overwhelming tasks into a small manageable pieces

Be prepared for pivots and set backs. If you can't get traction, pivot.. and don't look back after that. It's hard to leave "so much excellent code" but having an unnecessary baggage will negatively affect your future decisions

Sales and Marketing

Products don't sell by themselves. Why to build something you can't sell? How many products you know failed because of technology?

It's better not to hire anyone to do sales and marketing at first. Learn how to sell your product.

Good enough product + great marketing is much more probably scenario of success than other way around.

Target audience

You are not making startup for yourself even if you're in a target audience. You won't be objective about it

After choosing your target audience do some research. "Don't find customers for your product, find products for your consumers" - Seth Godin

Talking and listening to your target audience minimizes the risk of failure and making the wrong assumptions

At the beginning focus on your perfect customer only. Do not define them by demographics but by things they identify with (how they perceive themselves)

This is it for the first release. There's much more worldviews and themes I would like to cover, but at first I would like to verify my hypothesis that most of you will agree on. Let me know in the comments if you agree or not with certain points above and help me to develop this list further. The mission is to create a list that you can send to any newbie in order to realize some of their misconceptions.

What customers say they want is not what they really want

2013-03-22T10:39:00.000-07:00

People lie all the time, often unconsciously. Let's say you're a host of a meeting. When you ask a first person what does he want to drink, I bet almost everyone will choose water or strong black coffee, even though it's not their favorite drink. No one would say that 'weak latte with a lot of milk, cinnamon and whipped cream on top' is his choice and there are some reasons for that in every situation.

Believe me, if you make him a latte instead of a black coffee, this guy would be the happiest person in the world. There are a lot of other similar situations and - what's most important to you - it works with your customers too.

"I need this awesome feature to make my life better"

No matter if you run a software project for a client or listen to a feedback about your product, customers are dishonest with you. What do they really need is not a feature. They often communicate a deeper issue to you, and your job is to figure out what they really want. "I have enough of this with my girlfriend", you say. Yep, it's time to start analyzing and figuring out what's really going on.

Why is this happening?

It's just like with the coffee.

The request for a black and a strong one it's a result of the complicated equation. Somewhere, there's a real reason of what someone says, but it's hidden among other variables:

I don't want to make too much trouble for the host
I want to stay in the crowd
I don't want to hurt somebody's feelings (ok, maybe it's a bit exaggerated with coffee example)
I want to be accepted
and a lot more funny things hidden inside human's twisted brain

We need to go deeper

What you should do is to try to get rid of all these thinking patterns and try to focus on a real need. Emapthy is the skill you need here. You need to understand what customer feels, what he really wants and what are his expectations.

Don't accept all requests right away. Ask for the reason, try to understand what was on the customer's mind. Remember that people like to talk about themselves and their ideas.
Don't be afraid to disagree if you think it's a bad idea. But don't just say that they are wrong, it's better to ask questions and let the customer realize that he's wrong on his own.
Start digging. If you don't understand something clearly, don't hesitate to call and ask customer to explain why he wants something. Don't assume without any data, you'll be probably wrong.
Put yourself in customer's shoes. What is his biggest fear or pain? What is his worldview? Is there a pressure on him? Is he worrying about something? Asking these question will help you understand him.
If you want to go deeper, read "How to win friends and influence people" by Daniel Carnegie. It could change your way of perceiving other folks.

Remember that you'll be never 100% sure if you understand someone's decisions fully. That is why I don't belive in lean startup's customer interviews religion.

Ask yourself: what would Bill Gates do?

2013-03-20T03:45:00.000-07:00

I know most of you can't stand the guy, but you have to admit, that he created one of the most successful companies of the 20/21th centuries. That's the undeniable goal of all startups, so please forget all the hatred and focus on inspiring parts of his story. You haven't probably seen it that way, but Bill Gates was one of the first IT guys who tried lean startup strategy, without even realizing that it would have a name some day.

Learn from Microsoft

You probably can't recall ancient history of late '70s, but Microsoft was also a startup once. Bill Gates and Paul Allen didn't have much of resources that days, but it didn't stop them from getting the contract from IBM and making a breakthrough in their careers. How was it even possible? I'm sure that you know the story about Bill Gates selling MS DOS to IBM, when the OS didn't even exist.

Wasn't it a genius use of what we call "lean startup strategy" these days? He solved a problem, interviewed a customer and closed the deal. Pretending that your product is almost ready, it is the best strategy for earning money before shipping the product. They still use that strategy - think about preorders they offer on new consoles, operating systems and games.

MVP = Minimum Vendible Product

The only person who cares about features of your product is probably you. Customers usually don't even precisely test a product before purchasing it. All of the custom software systems deals are signed before anyone catch a glimpse of the first line of code. Why wouldn't you take advantage of a similar strategy while selling a regular product?

Creating a MVP doesn't mean you should build any prototype - the purpose is to validate your idea. I hope that Eric Ries would agree on my statement that MVP actually stands for Minimum Vendible Product. Whatever makes your product sellable go for it and validate your idea as soon as possible!

Are you sure that you really need to show your customers how it works and they won't get the idea without a little showdown? Create only the most impressive feature or module. No interest from potential customers will be a sign that you overrated your idea and already lost a lot of your time.

Should I tell you that your startup idea sucks?

2013-03-19T04:19:00.001-07:00

I just came back from a 72 hours hackathon where 7 teams had to create a fully functional mobile game of their own idea. My job was to advise them during the project work and prepare to sell their idea. It was fun, but I had a big dilemma - should I focus on encouraging and motivating them to realize how cool it is to create your own product or should I help them create a product that has a chance to succeed? The second option leads to telling someone that his idea sucks (and it could be devastating for a newbie).

This problem not only concerns mentors on the hackathons. We all have friends or meet people sharing their startup ideas. I was always very gentle with this situations: "It's awesome you started your project, go for it! Maybe you should focus on this or that, but it's still great". At the same time thinking that it's almost impossible to succeed with wrong assumptions, too big scope or incomplete team. I've had my failures and successes and I know how a bad idea looks like when I see one.

"With great power comes great responsibility", uncle Ben said to Peter Parker once.

If I had some experience as an entrepreneur is it my duty to help others avoid failures, even with the cost of ruining somebody's dreams? He'll probably avoid a great deal of disappointment. On the other hand you can discourage somebody from realizing his dreams. It's hard, especially when friendship comes in the way. What is the lesser evil here?

Cut down to size

There was a solid, motivated and skillful team on the hackathon. But what they lacked was a good idea. The one idea they came up with hasn't got smallest chance to hit the jackpot. We tried to put them on the right track gently, but it didn't work. They wasted the weekend on creating a decent prototype of a weak idea. What we should do from the beginning was to cut them down to size.

It's good they spent only one weekend on it. There is a lot of startups struggling with wrong ideas for months/years ending up with a decent product which nobody wants. In startup business, failure is an expected outcome, but we shouldn't encourage people to execute ideas that will probably fail. Remember that running a startup is a very stressful experience and failure could be devastating.

How honest are the founders on their expected failure rate?

I think they are not honest at all. That is why we should make them aware of that, especially when in our opinion expected failure rate is way too high. No one would start anything with the expected outcome of wasting months/years of their life and loads of money.

Just think how it is to feel the wasted months on a startup you stopped believing in? How it is to start losing all your energy and motivation while creating a product? I had this once and I regret that nobody explained it to me that I'm up a blind alley earlier. I've learnt in a very harmful way that we have to verify our hypothesis as soon as possible.

I would love to be devastated by someone who could explain to me why my startup had to fail.

A well-known secret of consulting companies

Why do development companies have info about "over 50 projects in portfolio" and only few clients logos on their site? Because a lot of their clients don't exist anymore. Their clients are early funded (or financed by the founders) startups that created a product and failed right after that. Believe me, this ratio is high.

It can be lower, if the offshore companies would be honest about what they feel about their clients ideas instead of silently accepting a new project. After developing tons of products, they (we) have enough knowledge to know that some ideas will definitely be a failure.

How to improve your product?

2013-03-13T07:06:00.001-07:00

No, this post is not about a process. A process is good and make us feel safe, but often slows us down.

No, it's not about estimations and specifications. A good plan helps us deliver what we planned, but not the best product. And often just limits our creativity.

And no, it's not about communication. If you have problems with communication then, well, just start to communicate, duh.

So what is it about?

Maybe it sounds childlish, but this post is about understanding each other. And no, I didn't come up with this idea after watching one of the disney movies but after struggling with the same mistakes over and over.

I was always a product guy. Analyzing, thinking, roadmapping and delegating tasks. But over a year a go I started to learn skills that shouldn't be my worry. Code, graphic design, UX, sales and even game design. Yes, I know I won't be an expert in all of them. I know that I'll probably suck at most of them. But it's not the point. The best way to understand somebody is to:

Put yourself in someone else's shoes

Don't you feel sometimes that you have no idea how other team members work look like? Why did he something this way and not that way? I often had a feeling that we were on the different sides of the table, often forgetting that the result we all wanted was the best application ever created.

Not an application with the best design. Not with the best UX. Not with the best code. Not with the brightest world-changing idea.

If the whole is not great, nothing is

Not seeing the project as a whole is a common cause of fails. I've seen dozens of beautifully designed, well written apps that failed. The best Idea won't fix the infrastructure problems, and the best UX won't help if the copy is tragic.

"But what can poor little me do with that? It's not my duty to [...]"

First, start seeing the project as a whole

The easiest way to do so is to learn things outside of your comfort zone. Developers, learn some design. Designers, lern basics of html/css at first. Product owners, learn something more than just owning. And most important, the whole team have to understand the idea behind your application. There is a basic rule in game design that "the team have to love their game if they want to succeed". How can your team love your product if they don't understand its purpose?

What will you gain?

You will understand why and how, not only what. You will start questioning. Why do we implement this feature? Why do we use this template? Why don't we make it simpler? Is there any faster/better way to do it?
Secondly, you will think how to make life easier for the other team members with your work. A well prepared PSD. A well described feature.

Last team member should be... a user

Even if you work on a product where you are a part of your audience, remember that you are not your user. You see things from a different perspective, through your emotions. The same story: to create something useful for your audience, you need to understand how is it to be them.

How can I be in my user skin, you ask. Just read some blogs that your audience likes, don't skip the comments, see what language they use and what they whine about. Follow right keywords on twitter, find places (groups, forums) where they communicate. Don't ask, just investigate and learn.

So guys, I encourage you to step out of your comfort zone and to start to understand each other (...to make world a better place, yep). And this will improve your product.

You still have doubts which steps to follow next in order to create products more effective? Let me help you through this process:
sign-up for our course covering this topic.

You don't need a UX specialist

2013-03-11T08:53:00.000-07:00

You don't have to be a UX specialist to say that UX of a certain app sucks. All you need to have is a common sense.

I had this feeling over and over, but never thought that I have expertise to do something more than saying that it sucks. In projects in which I've worked, there always were graphic designers with UX knowledge and it just wasn't my job to do that. But lately, when we started to share competences in our team, I realized that I can easily gain skills to do a lot more than whining.

UX is all about common sense

On the early stage of your product there should be only must-have features, there is no place for nice-to-have frills. Therefore the UX job is not so tough as it seems to be - there are only few things to choose from.

Think about apps that made you a headache because of a poor UX - I assume that most of them were:

in the late state of development (core features were mixed with nice-to-have addons)
the purpose and the idea behind app aren't so obvious.

I'm sure that you have neither of these problems.

Choose most similar benchmark. It will be your theme

For example - when you are creating internal communication stream your benchmark could be facebook group.

Why do you need such a theme? In UX you are mainly operating on conventions and there is a 99% chance that a successful app you choose as a benchmark uses the conventions right. The more famous app you choose, the bigger chance that they did UX properly. Trust me, if you don't have UX competences in your small team, this is the simplest way to "hack it" and validate your idea.

Some steps I recommend to follow next:

Make a hierarchy of all the features and things you want to communicate. It will help you decide where to put what.

Set the right way of thinking - think what user wants, not what you want user to do. What problem this feature solves?

Make prototypes fast. I advice using mockups services like Balsamiq or UXpin. It will take you less than an hour to make prototype if you have choosed design pattern already

Question why: why is it more important? why are this feature have to be here not here?

Read: "Don't make me think" is a must, then scan for UX magazines and blogs.
Sign up for our course on how to launch your app in 5 days:

And just put the right things in right places using your common sense

I'm not saying it would be perfect but there is a big chance it will be good enough. And good enough is all you need for now. After you are done you can consult it with UX specialist (or post it somewhere on the web) to see if you did some obvious mistakes, it happens.

Not having a UX specialist is another excuse from not following your dreams and not lauching your app. It's better to belive in yourself and to do the job on your own.

Dear Startups: stop begging investors and pitch your clients!

2013-03-07T00:13:00.000-08:00

Do you have a mindblowing business idea? Is market research telling you, that it’s gonna sell like crazy? Millions of clients are waitng to make a change in their lives by using your product? So what do you do? Oh, wait! You need money to make it real, so you’re going from one door to another trying to get funding. What a bullshit! I’m sure we all have belived in the funding bias, which made us convinced that getting an investor is the most crucial success factor of a startup.

Earn your own money

Selling your idea is the easiest and the mightiest way of getting a positive cashflow ever created. Does the name kickstarter ring a bell in your head? Do the guys on kickstarter have anything else than a cool idea? They do exactly what you should do – you have to make your clients to pay for a product, which doesn’t even exist. How to do that?

Instead of wasting time on budget planning, pitch decks and investment proposals spend one evening on creating your new products' landing page and 3 slides of a presentation. Yeah, it's really so easy to preprare for "launching" and starting sales of your product. You don't know how to sell your product? You thought that investor will tell you evertything?

I'm sorry, but nobody is going to spend more than a dollar on your idea, if you don't have a clue about your business model and sales strategy. Get to work and schedule as many meetings as possible, cash will follow very soon and you will have funds for creating your MVP. It's going to be much faster than applying to 50 accelerators and pitching 100 VC's.

In the end how much can you get during the seed round? $10-20k? Just one corporate client is going to pay much more for your service. Forget about investors and focus on customer development - this strategy is going to bring you only benefits.

Clients vs. Investors

Getting a client means that there is somebody who wants your product and that you follow the right direction. Getting an investor means just that there is somebody willing to risk their money on your experiment but you still have to validate your idea.
Even one client is a great social proof for other potentially interested people or companies. You have somebody willing to test your idea with you. You can make case studies, you can put their logo on your website, you will get testimonials. The only social proof you get from having an investor is that you won't broke within the next 3 months.
If you can't sell your idea to anybody, it's shitty and you will know it straight away. If you can't get funding, it doesn't mean you won't succed and find customers for your product. Investors often have strange criteria, so it isn't the right validation of your idea.
You can't argue with the fact, that investors bring a lot of know-how. But you can join startup competitions, hackathons, etc. where the same people will share their knowledge with you.

Invest your time in the right actions. When you build a great product investors will contact you, so get to work and stop begging for money. "I can't start, because I don't have funding" is the lamest excuse not to change your life ever.

Developers, learn to design!

2013-03-05T08:58:00.000-08:00

Do you remember the time when you built your first apps? You were probably the one-man-army, responsible for the whole idea, development, design and copywriting. Stumbling the web to find best templates or designs to reuse, learning basics of UX and photoshop - just like an adventure. Those were the days.

Then, you've got your first "real" projects or job. You've learnt that it's designers job to provide you designs. Everyone in the team has his own role in projects, different competences. Developers, designers, project managers, product managers and so on. We all stick to these narrow fields and learn to become experts in them (and than we get old and die, yep I had to add this).

It's just wrong

Maybe not in all cases, but mostly it is wrong. Have you ever wonder why does it take so long to change color of "this little unimportant button"? Product owner tells project manager to change it somehow and than the project manager goes to the designer. Designer whines about "destroying his beautiful design" and in deep pain change the color a bit. Proposition of change goes back to the project manager, then to the product owner. If it's OK (and it's not always the case) it goes back to you eventually. Now imagine that you talk with product owner and suggest change from #c21d2e to #c21d2f and show him how does it look like in live app. Two minutes instead of two weeks.

"But I don't have talent", you say.

You don't have to be a freaking Picasso to suggest color change

Design is not a rocket science. It's set of rules, just like programming. There are few principles that every team member should know about design. And there are tools to help you with it. In order to make software development process more efficient we should all share some competences and the design is one of the most important.

Remember that design in most cases does not have to be perfect, good enough is OK. With tools like twitter bootstrap it's almost impossible to make something look ugly.

Where to begin?

Take a look at twitter bootstrap. It's propably the best framework to make good-looking front-end fast

Buy "Don't make me think" - it's one of the best books about UX. After you read it, you will know enough to decide what element should be where and why in the app.

Improve your aesthetic eye by stumbling well-designed apps. Just visit sites like Best Web Gallery and Screenalicious

Don't invent anything, just copy. Designs don't differ too drastically from accepted aesthetics (otherwise your designs will be rejected by audiences)

At 123ship.it the whole team shares some competences. I am the product owner in most projects, but I'm learning to design and code. Sometimes it's easier to make some changes by myself than delegate it.

The biggest advantage of sharing competences is that the team feels responsibility for the whole project, not only its small part. You'll be surprised how this affects productivity.

Last thought: imagine how easier would it be to work with designer that knows basics of code? It works in both directions.

Google docs killed our remote communication

2013-03-03T13:40:00.000-08:00

It`s now over 6 months since we switched from google docs to real-time wiki hackpad. I decided that it is a good moment to share some insights how and why do we stick to it so far.

Our team works remotely and that's why every tool that empower our communication is crucial for us. We often test new tools and to be honest very few meet our expectations. Suprisely, hackpad became one of them.

What is hackpad.com?

Hackpad is real-time wiki for creating collaborative documents. In a few words:

you can create text documents,

share it easily with others,

edit in realtime,

link between documents,

create collections.

In comparison with googledocs, hackpad is much simpler. There is only few options to format text, no option to change fonts, colors, make charts etc. It`s like collaborative Microsoft Word with only most basic features. And this simplicity is one of the first things that brought my attention.

Before: Communication and creating documents in google docs

We needed documentation for all sort of things - specifications, discussions, important decisions, researches, content creation, ideas and asynchronous discussions. Earlier, with googledocs, we created docs only when there was no other option. We pushed other channels of communication to the limit, and often the result was a communication mess.

Creating a doc seemed to be necessary evil (we are lean, we are startup, we don't need documentation). As I think about it from perspective, it made us a lot of problems.

After: How communication changed after switching to hackpad

With hackpad simplicity we started to create new docs right away. It take less than 10 seconds to create new "pad" and share it with others. And after that, you just start to type (ideas, tasks, discussions). In our case these pads often change into long (and productive!) discussions. That would have never happened with googledocs.

On the other hand, there was a moment when it started to become a mess. A lot of different hackpads with million of thoughts, often out-of-date or unnecessary. But the solution was easy - we just had to organize all pads on weekly basis. Remember - when productive communication just happens, do not try to cut it down, focus on better organization.

Google docs have a lot more features. Some of them seem important, but the thruth is when you start using hackpad you realize that you don't need them at all. Simplicity wins.

Lean documentation

When I think of the way we create documentation now, there is no better term to describe it than "lean documentation". We create often and there is a lot of unnecessary documents. But we validate it and just delete not-so-important-ones, leaving only meaningful reference. I bet it will improve your team communication (especially if you have remote team), just remember:

Don't be afraid to write!

Share your thoughts, doubts and ideas and make it possible for your whole team. The easier way, the better. Communication is crucial and every misunderstanding could be the cause of failure or delay.

Use cases

Fast to-do lists. In some cases management tools (in our case trello) seem too slow and we create quick to-do lists in pads.

Content creation. I'm writing this post on a hackpad, sharing it with team and editor :)

Ideas and discussions. When somebody has a new idea worth considering, we put it in a hackpad and start to discuss if it makes any sense.

Text references. Every valuable piece of text about any of our projects is added to project collection.

Every piece of text that need to be written down fast - after inspiring meetings or customer interviews. If it's valuable, we move it further (for example to the spreadsheet with customer interviews).

Small texts that can be changed by others like meeting agenda.

Communication with client. It's often more productive to send link to pad than writing an e-mail with things about project to discuss. Trust me, it's faster and more effective.

Have you ever used hackpad or other wiki alike tool? I would love to hear your experiences with documentation!

HaaS: Hackatons as a Service

2013-02-23T06:22:00.001-08:00

You probably know hackatons idea, right? For me, it`s just the coolest way to create software. You have 48h or 72h to deliver fully functional application, you camp in one place with team of super-motivated superheroes, buy pizza and beer and just hack together in party-style environment.

It`s ofte more like party than work, but still the effect is fully functioning, often stunning application. If you dont believe, just check out these apps: http://railsrumble.com/entries/winners. 48h, duh?

After hackatons you just come back to normal environment and get back to projects you have been working on months or years. In this normal world, there is a law that software development is usually a long process, and "this is just how things are". But what if it was possible to get a similar hackathon effect for your application?

The idea that struck my mind is simple: let`s take what we can learn from hackatons and apply it to apps we create for ourselves or our clients. At first, it sounds almost impossible, but is it?

What we can learn from hackatons:

realtime communication. "And not a single mail was sent that day". Just imagine how much faster your application would be shipped if there would be no ten-mail-long conversations with client/designers/product managers about color of totally unimportant button
teamwork and responsibility. Everyone is responsible for the whole project. There is no matter if you are designer or developer - the ultimate goal is to deliver working app
focus on must-be features, not nice-to-have. We need to deliver something really fast, so there is no time for focusing on this "button color drama". We need to remember that often nice is good enough
time pressure. We need to deliver it. If something takes too long, just try to find simpler solution instead of spending a week on it. It makes us more motivated, on the other side it can be stressful. There is no simple answer on this one, but it`s worth to mention.
hacking. "I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it." - said Bill Gates. On hackatons, we try to find simplest solutions and it turn on different way of thinking. It`s always good to think like a lifehacker.
no time for the long process. Process sometimes helps, but always slows us down. In motivated team with good communication there is no need for double-checking and managing. The team manages itself.

It`s just a tip of an iceberg, but these principles can help us to make software faster. And the ultimate goal is to be able to go to your client and say: "Hey, we can make yours app MVP in 72h. Come to our office, buy pizza and beer and lets hack this up". And finally, to offer hackaton-style creating apps as a service.