Wednesday, February 28, 2018

Through a Mirror Darkly - The Not So Positive Look At Startups From The Inside - Part 3


This is Part 3 of my thoughts on the things that can go wrong in a startup.

Beware of Idea People Bearing Contracts

Startup weekend style events are numerous.  They are a great way to flesh ideas out and to build a Minimum Viable Product (MVP).  The idea is that a team of people comes together, works together, and at the end of the event, presents their idea, some market place data, judged by a group of entrepreneurs that have successful started and either have a running company or have successfully exited, and hopefully win the event.  After the event, it is hoped that the team will stay together and push their idea forward.  Granted all of this is a tall order, but startups are hard, not easy.
Unfortunately, there is a disconnect between what the hoped for at startup weekend event, and how people with ideas view them.  Many entrepreneurs that are idea people have a different view.  These people view their idea as the be all and end all.  They don’t want to share that idea with anyone else. However, they are stuck in that they do not have the technical skills to push their idea forward.  Somehow, the idea entrepreneurs have decided that these type of events are a good place for them to find “free labor” for their idea.  I have seen several that have come to these events with contracts that will allow them to get this “free labor” and leave the developers with nothing.  Ultimately, the problem here is that an idea entrepreneur sees:
·       Anyone could steal my idea.  Ideas have little to no value on their own.  Unfortunately, many people think that the idea is everything.  If the idea is everything, they feel that they are within their rights to attempt to keep people from stealing their idea.
·       With the view that the labor is free, there is no differentiator between developers.  One developer is as good, or bad, as any other developer.  The problem that entrepreneurs need to understand is that people do matter. 
·       Based on the concept of no differences between developers, there also tends to be a lack of understanding of the difference between an offshore and onshore development.  Onshore development tends to work better for a startup.  This is due to multiple reasons.  For example, the developer having an intrinsic understanding of the user.  I would expect an Indian developer to understand an Indian consumer.  The same is true in the United States, Europe, China, and everywhere else.  Another issue is timeframes. Startups need quick turnaround. Communication when everyone is not in the same area is hard.  There are advantages to offshore development, however, that is a different article.
Most people at startup events are well meaning people.  Not everyone comes bearing contracts. Unfortunately, I have seen several that do.  From experiences, these never tend to work out.  The people tend to have interesting ideas that have potential.  Good developers tend to not want to work with these people. Instead of an idea that can grow, they end up being stuck by themselves.  If success is a function of the team, they are stuck without a team to move their idea forward.

Who Owns the Code?

Clearly everyone in the startup owns the startup, and they own the code (or graphics, marketing documents, etc).  That’s the popular thinking.  Nothing could be further from the truth.  Barring a contract that states otherwise, and no one ever pays attention until it is too late, code is owned by the person that created it.  This is a common problem in startups.  The code for a startup is not owned by the startup unless it is explicitly handed over to the startup.  

Coachable

How coachable are people?  How coachable are you?  Can you stand the critics of your existing idea?  I can guarantee that people get too attached to their ideas.  I know I do.  Why?  Because it is a product of my brilliance (not really, but you get the idea).  Several instances that I would like to mention:
·       We were at a Saturday morning meeting of our startup years ago.  We were trying to explain to the managing partner that his initial idea needed some tweaking and how to move this forward.  He could not accept that no one wanted his idea that he had crafted 125 pages of documentation into.  While his general idea had merit, we needed to move it about 20 degrees to be right of his target.  He refused and kept saying “It’s not my plan, it’s not my plan.”  Some key changes to his plan, and we would have been winners.  But we couldn’t get him to change his idea, so we were all losers.  It is quite an amazing site to see that some people would rather be wrong than to make a change to their idea and be a big winner.  Ego is an amazing thing.
·       At one startup weekend event, during the discussion we were having regarding business models, she wanted to give everything away for free and to mine the data on the backend for income.  That can definitely remove the “stop sign” for users to use the product, but isn’t really a good mechanism to grow income.  I stated my objection to this and that we needed to have a licensing model to generate income.  I left it at that, so we standing up doing our final presentation on Sunday night, and she goes into the “give it away and mine the data on the backend business model.”  I could not have looked more disappointed as I am running the demo.  When we asked why we only finished third, the feedback from the judges was “horrible business model.”  We wouldn’t have won, but we would have finished second.  Here was someone that had been specifically told, “don’t do that” and did it anyway.
·       People are not going to automatically buy “your genius.”  You have to go out and sell it.  That could be “buying ads” on facebook, google, or somewhere else.  If you are in the SAAS world, its probably shoe leather and knocking on doors.  So, let me get this right, you want to be the “sales” guy, but don’t want to sell?  SMH
·      I often think back and look at the post mortem of “99 dresses.”  What did this person (Nikki Durkin) do that was so bad?  Clearly, she was not a bad person.  She had to have a tremendous level of smarts to get something going.  She got accepted into Y Combinator, which is an accomplishment in and of itself.  But, It seemed that there was a problem, and that problem was that the technical people kept leaving.  Finally, down in the blog post describing their post mortem, it all comes together for me with this paragraph:
I remember one day Marcin joked that I was a control freak, and I was really surprised. I’d never perceived myself that wayI just liked things done a certain way and to a certain standard that matched the vision in my head. When it came to non-99dresses related stuff, I thought I was pretty chill.
This person had several versions of their product all built by different people.  It all came together for me.  She had replaced multiple technical cofounders.  When you are too controlling, you tend to push people away.  Sometimes you have to let go.  It doesn’t matter where your buttons go.  It doesn’t matter if the buttons are blue, red, or green.  Think about solving the problem, not the specifics of the buttons.
The stories go on and on and on.  You have to be all in on a startup.  You have to do things that have worked.  You have to understand your situation.  You have to do things that you may not agree with, if for no other reason than to just try something different to see if the angle has some success.  You have to be coachable, you have to be open to new ideas, and you have to be open to your ideas not being that good.  And yes, that means that my ideas may not be very good.

Summary

Startups have risk.  They have risk for the developer.  The risk needs to be shared by everyone, not just lumped on a single person.  Hopefully, this article has brought out some of them.  Sometimes you may need to just walk away.  It is up to you to decide if the scenario is bad enough.  Good luck on your startup.

Resources


Wednesday, February 21, 2018

Our Golf App


I wanted to share my feeling at watching the scoreboards on Sunday February 18th, 2018.  It is awesome to know that I’ve built a system that people can use and I don’t have to be around to see.  It’s hard when things start.  Your goal when you start is not to have everything perfect.  Your goal is to have something that people can use initially.  It’s not perfect.  It is a start.  Initially, it is called a Minimum Viable Product.  Minimum is the key.  You start with the minimum set of features that people can use.  Over time, you add features.  You improve the product.  That is called iteration.  And that is what I have done.  I have taken a product that I had to go to the golf course to run to now, the golf assistant procs can run the application with no interaction from me.  For the club games, we have things to the point where a golf pro just needs to:
  • Select which club game a group is playing.  The game type, game settings, and money are all preset.  The only thing the pros need to do is select the players, hit the start button, and the players are off and running.
  • Players and teams can setup prebuilt side games quickly and easily while on the course.
  • The players handicaps are stored and updated as necessary.
  • The scoring and money is calculating in real time.
The club games are just about as easy as can be to setup.  The only thing that could make it easier is the brain tie in where you just think it, and the game, teams, and players are setup for you.  What does this do?  It eliminates
  • The 20-90 minutes afterwards in figuring out the score and the money.  We talk about wanting to have time back in our lives.  If my game was so complicated that it took 90 minutes to get my money, I’d want out quicker as well.
  • The errors.  If you play a handicapped game, 60-70% of your scores are wrong.  Don’t you want that better?

And then there is the charity games.  This is truly a package that any club/course could use. We have this down to a package that you import our spreadsheet that you have filled out, print out the qr code page, and the users download our app.  The user starts our app, points at the qr code, and the teams are keeping score.
  • The tournament director can fill out a spreadsheet of teams and players.  This can be imported into an event.  Boom, the teams and players are created.
  • The players will need to download an app for either the iPhone or android app stores.  With this app, the players can scan a supplied qr code.  The supplied qr code allows a person to start scoring for their team.
  • The only thing the golf pro staff has to do is put the print outs of the qr codes on the golf carts or handed to the players as they check-in.  Scan the qr code, and scoring can start.  That’s it.  
  • This saves somewhere between 60 & 90 minutes after the event for players in seeing the scoreboard and results.  This cuts down on the time for the golf pro staff as well as all of the players.  Time is money.  
  • The results are calculated in real time and follow the USGA guidelines for tie breaking.
  • Pictures and video can be uploaded in real time and are immediately available in the application.
All of these features create a truly memorable experience.  I am very proud of what has been built.  I am working to get our product out to as many charities as possible.  Please contact me so that we can help your charity generate more money from its charity golf events.
Here is a link to the Boys & Girls Club of the Smoky Mountains.  Please check out the pictures and videos that are on the score board.
Boys & Girls Club Smoky Mountains on the River Course at Sevierville Golf Club - https://golfeventscores.azurewebsites.net/PublicScores/SingleScoreMultiplePlayersSummary?TournamentId=31427

Overview of Tournament Director : https://www.youtube.com/watch?v=LhMFaC-is04

Overview of the Scramble System: https://www.youtube.com/watch?v=uUnzJZVJSb4

Sunday, February 18, 2018

Through a Mirror Darkly - The Not So Positive Look At Startups From The Inside - Part 2

This is part 2 in my series on the things to be nervous about startup risk for the developer.

People Doing Their Work 

Unfortunately, people tend to over promise and under deliver. In a corporate environment, there is at least some amount of requirement that people do their work. In a startup, some people just won't do their work. I've seen this across several startups. The most jarring example was a startup that needed to raise money. For whatever reason, the founder would say that they were going to talk to angels and VCs. In reality, they never made the first attempt. People are often intimidated when they are out of their comfort zone. The last thing that they want to do is something that they are uncomfortable with. You have to watch this and hold people accountable. If I am a developer that is expected to give up their life for a startup, I am expecting other people to do the same thing. To push this along, one has to be really careful. Just asking "why haven't you done this yet?" is probably a bad question. Asking what you can do to help move something along is probably a better question.

Helpers

Sometimes, you have helpers. As a developer, you have people that want to explain to you how to implement something. They may or may not actually understand what is happening. Unfortunately, they tend to think that they are subject matter experts. I refer to these people as "drive-by subject matter experts." Don't get mad at these people. They are trying to help, however, their help is going to cause more harm than good. The danger of these people is that they will get locked into one thing. They might claim that the one thing they are talking about is an absolute requirement when the feature they are talking about is really just a "nice to have." How do you handle these people? These people are really just looking for something to do. I've always worked on giving them something to do that is helpful to the startup, but not associated with the development. Get them to write blog posts, test an application, or do something else.  Just come up with something to get them out of your hair.

Money

Financial risk is a major problem. Negotiation to handle this upfront is key. Unfortunately, this rarely happens. People are working their hardest. Money gets forgotten about until it is too late. Unfortunately, the most money today gets spent on development. Unfortunately, development is where the most stress in a startup is. It is unrealistic to put the developers at financial risk in this area. Developers need to protect themselves in this area. I've had this issue come up three times personally. The best example of this is a question on Quora asking for advice on how much personal financial risk is acceptable for a developer at a startup. The question implied that the developer was being asked to indemnify the startup investors against financial loss. Startups are risky, and that is the nature of the beast. Each situation is different. Do your best to protect yourself. There is often the expectation that developers will work for free forever. Nothing could be further from the truth. I don't mind helping people, but my help comes with several conditions:

  • I'm not doing this for free forever. I don't mind helping you get into first gear with a prototype, but you need to be out there working on customers and funding. I've had this happen.  Nothing kills a relationship quicker than "We're going to fail without you, so this is your fault."
  • I'm an investor. My investment is my time and my code. Respect my time and my code. Don't bark dates at me.
  • Code isn't to just be handed around. Code has business rules within it. I'm not sure why a new "low cost" developer is going to immediately understand business rules, yet I see this a lot, especially for those that do not have software development experience. Writing code for a startup is a two way street and a long term relationship. You want people that you can trust, on both sides. Can I trust you if you want to just ship code around with no thought of the how things work?

Existing Code

Existing code that a startup wants you to take over, wow, is that dangerous. The expectation of the startup is that with a few well-placed corrections, their code will go from a complete mess to a smooth running application that scales. This never happens, and here is why:

  • Code was written by someone that is no longer in the startup. There is a reason why they are no longer in the startup. The most common reason is that a new feature was needed and the original developer could not deliver. The call for a new feature became deafening. The original developer got tired of this, or the rest in the group go tired of waiting. The end result is that the person is no longer in the startup. 
  • Code that was written by someone else has business rules embedded in that you are not privy to as well as idiosyncrasies of the original developer within it. You need help in deciphering this, however, that person is not around. Even if you can get ahold of them, that person is not going to be forth coming regarding any ideas or solutions.
  • Most likely, the previous developer was not paid for their work. They just want out. They are working on other things now. When you are in this situation, you, and the startup, are better off just starting over. This one is a tough pill for everyone to swallow. To the startup, this looks like they are throwing away their existing investment. They are. Software that doesn't work results in a sunk cost. People have a lot of trouble coming to this conclusion. The non-developers in the group will view this as additional delays and will be against the idea. The attachment to existing code seems to border on the "Stockholm Syndrome." Almost always, there will be too much trouble trying to breathe life back into the code.  Don't waste your time


Part 3 of this series will be out shortly