Inside My Brain

Thoughts about startups, tech, marketing, and life

CATEGORY: Startups

Targeting a Niche Audience Early – Lessons Learned from Past Startups Part 5

This is the fifth post I’ve written about some of the mistakes I’ve made with past startups. You can find the other four here:

  1. Alignment with Idea – Lessons Learned from Past Startups 
  2. Alignment with Co-Founders – Lessons Learned From Past Startups Pt. 2
  3. Real Customer Development – Lessons Learned from Past Startups Pt. 3
  4. Testing Mockups Before Coding – Lessons Learned from Past Startups Pt. 4

Hi! Sorry, I didn’t blog last week off because I was traveling for a wedding. Did you miss me?

Anyway, today I’m going to write about a big mistake I’ve made in my past startups – not focusing on a niche audience in the early days.

target niche audience

Dokkit – a calendar tool for everyone

We didn’t get very far with Dokkit because of team issues, so not selecting a niche audience didn’t really bite us. But the path we were going down was for a very generic audience, so it would eventually have caused problems.

The plan was to ingest a whole bunch of different types of calendars – the schedules of sports teams, concert halls, bars, restaurants, you name it – for anyone to download.

Thus, we were going to try to make everyone happy, and probably would have made no one happy.

The smart thing to do would have been to focus on one type of calendar – sports teams’ schedules, for instance – and reach out only to sports fans to see if Dokkit would add value to their lives. If so, great; we could continue to build out additional functionality for sports fans. If not, we could have either stuck with sports fans to try to solve other calendar or scheduling problems, or move on to another audience.

We didn’t even get to run into the audience problem, but we would have eventually.

ribl – a conscious (and wrong) decision to stay broad

We had a choice with ribl – to launch it into the wild and see who would use it and for what purposes, or to focus on a niche audience and iterate through different types of users if things didn’t seem to be working.

We chose the former, and received feedback like “I don’t know what to post,” and “This seems cool but I’m not sure what to use it for.”

It’s tough to grow an audience who doesn’t know what your app is supposed to do. And to tell you the truth, we didn’t really do much about changing that.

What we should have done is pick one audience – maybe concert attendees – and focus on how they shared their experiences at concerts and events. If that didn’t work, we could have moved on to restaurant goers, or sports fans, or another niche local audience.

We also had a choice to focus on a specific geographic area. While we did concentrate our efforts on the DC / Baltimore area, we didn’t solely focus on it. We actually had users all over the world – from San Francisco to Brazil to China – but that was actually a bad thing, as ribl needed a certain density of users around a specific location to have value.

Heck, we launched ribl at South By Southwest, and I spent thousands of dollars and sweated my ass off in a frog suit. It was fun but completely draining, and eventually worthless.

mike in frog costume

This frog was not that happy at the end of SXSW.

Facebook started with Harvard only. Foursquare focused on NYC. ConvertKit focused on a specific type of blogger (see the “Working in Niches” section of this blog post from Groove.)

Focusing on a niche audience in the early days in crucial.

Applying this to WinOptix

From my customer development interviews, I’ve narrowed down the initial audience for WinOptix to professional services federal government contracting companies with at least $3M in revenue. Pretty focused and descriptive, huh?

While I’ve spoken to very large contractors like Booz Allen Hamilton and Raytheon, and much smaller govcons that you’ve never heard of, these conversations have helped me eliminate these types of companies from my target segment.

And while WinOptix certainly has applications for state and local government contractors, ad agencies, and anyone who responds to RFPs, I’m not going to worry about those segments now.

Focusing on my initial target audience will allow me truly understand their needs and build a product that solves their problems. I know we may still be wrong along the way, we’ll be in a better position to adjust accordingly with a smaller, niche audience.

Conclusion

Starting with a small target audience is so important.

You can deeply understand their needs and solve their problems. If what you build isn’t working, you can either solve a different problem or move on to another audience who might have similar problems.

But if you try to solve everyone’s problems, you’ll solve nobody’s.

What are your thoughts about targeting a niche audience in the early stages of your startup? I’d love to hear your thoughts in the comments.

 

Testing Mockups Before Coding – Lessons Learned from Past Startups Pt. 4

mockups

This is the fourth post I’ve written about some of the mistakes I’ve made with past startups. You can find the other three here:

  1. Alignment with Idea – Lessons Learned from Past Startups 
  2. Alignment with Co-Founders – Lessons Learned From Past Startups Pt. 2
  3. Real Customer Development – Lessons Learned from Past Startups Pt. 3

This week we continue the theme of customer development mistakes I’ve made in the past. Similar to last week’s post, this one is about building the application too early, and how you can test your concept with wireframes and mockups before coding it.

Lack of testing mockups for Dokkit and ribl

We didn’t do any customer development for Dokkit and built an alpha version of the app too early.

After some debate about what the app might look like, my co-founders cranked out the V1 of the app in a couple of months.

A smarter path would have been to create mockups of the app and test them with our target audience.

You can create clickable mockups using tools like InVision, Balsamiq, or Mockflow (which I use) that simulate how the app might work and behave. It won’t look like the polished app you envision, but it can reflect the core features and functionality that the first version of your app might have. And you can create pretty detailed mockups in a few hours or days, not months.

Same with ribl. Instead of spending a couple of months to build the first version of the app, we could have created mobile mockups with InVision, Fluid UI, or the many other mobile mockup tools on the market.

And we could have tested these mockups on both Android and iPhone before spending all the time building for both platforms (another big mistake that I’ll probably blog about in a future post).

Because you can edit mockups easily, you can rapidly incorporate your testers’ feedback into the next version of your mockups and test them again. This rapid iteration cycle will allow you to continuously improve the “product” to the point where you’ll feel pretty comfortable that you’re building something people want.

Testing mockups with WinOptix

After I believed that the concept of WinOptix was validated via over 40 customer development interviews, I started working on the mockups.

It took me a decent amount of time putting these mockups together because I just didn’t have a strong vision of what the app might look like. I got some great input from Dave and Carolina, the developer and UX designer whom I’m working with, and incorporated their feedback into the designs.

After we were done with creating the mockups, I had a bad feeling that the tests were going to go horribly and that the mockups were completely wrong.

There was only one way to find out.

I reached back out to the people whom I interviewed and up until today, I’ve shown seven of them the mockups.

We weren’t as wrong as I thought we’d be, which was pleasantly surprising. I received some excellent feedback about changes that need to be made, features that should be added and subtracted, and what parts of the mockups really stood out.

It would have taken a few months to build a first version of the app that I mocked up in a couple of weeks. So we saved a ton of time, and I saved a bunch of my development budget.

My goal is to show the mockups to at least 15 people.

The ideal situation is that one of the test subjects becomes so impressed with the value that WinOptix might bring to their organization that they’ll pre-pay us to build the app. If that doesn’t happen, hopefully a couple of the respondents will agree to trial the app when our V1 goes live.

Regardless, we’ll review all of the feedback and determine what changes need to be made and how to proceed from there.

Conclusion

Testing mockups is a continuation of the early-stage customer development process and is a MUCH cheaper and faster way to obtain feedback from your target customer.

Your mockups might be completely wrong, or they may be on point. Either way, you’ll have a much better idea of what your next steps are without spending tens of thousands of dollars and/or months of your time coding the first version of your application.

We’ll see what happens as things progress with WinOptix, but testing mockups has been really beneficial so far.

I learned this lesson the hard way and I hope you won’t have to!

Here are some other resources about how to use mockups before building your app:

What are your thoughts about testing mockups before coding your app? Have you had success doing this? I’d love to hear your thoughts in the comments.

Real Customer Development – Lessons Learned from Past Startups Part 3

This is the third post I’ve written about some of the mistakes I’ve made with past startups. You can find the other two here:

  1. Alignment with Idea – Lessons Learned from Past Startups 
  2. Alignment with Co-Founders – Lessons Learned From Past Startups Pt. 2

This week we’ll talk about the mistake I’ve made with customer development.

Customer development is super important, and I am totally guilty of not doing enough of it for my first two startups.

Customer development can be simply defined as talking to your potential or current customers to learn about their problems, needs, and wants to inform the solution that you’ll build for them.

It is SO important during the early stages of your startup where you need to discover the right market for your idea, validate that your idea is actually needed, and determine the initial set of features that will be built into your product.

Let’s see how I screwed this all up.

Dokkit

Build, build, build.

That was my mindset when working on Dokkit, the smart calendar app I worked on.

I pitched the idea at a Startup Weekend DC in November 2011 and while I didn’t get to work on it, I received amazing feedback from the crowd.

I also received many excited responses from my friends and family about the concept.

So I thought – let’s build, build, build.

We did get an alpha version launched and tested. But before that, we really should have done customer interviews (we did zero) to learn more about our potential users.

While we ultimately failed for founder alignment reasons, doing customer interviews would have benefitted us in a number of ways:

  1. We would have learned about our potential users’ needs
  2. We wouldn’t have wasted a lot of time building instead of learning
  3. This customer discovery phase could have been a test project where the team could have learned more about how well we would work together – a date before getting married

Not doing customer discovery for Dokkit was a big mistake.

Ribl

The ribl team did some customer discovery, but not nearly enough.

We had a vision of what the app would look like from the start, and we were very guilty of wanting to build it fast.

Across the three team members, we performed a total of about 30 customer interviews. That’s a decent number of interviews, though with three people, we could have certainly done more.

But the real problem was that the interview questions didn’t dig deep enough to truly extract what problems users faced in discovering local news and events, or if there were any problems at all.

We were blinded by the desire to build something fast.

I’m not against moving and building quickly; that’s a key advantage of startups vs. big companies.

But building something fast solely based on your vision is a mistake.

If I had to do it all again, I would have definitely performed more customer interviews until we had a relatively clear direction of what the product should do.

It is difficult to come up with a hard and fast direction from early-stage customer interviews. The aggregate feedback is cloudy, at best.

That’s no excuse to just jump into building something, like we did.

Applying this to WinOptix

I’m not making these mistakes again.

I’ve performed over 40 interviews with government contractors before even thinking about building anything. The feedback from these interviews transformed my initial idea to the very different concept that WinOptix is now.

Based on the feedback, we’ve created mockups and are testing them with potential customers. Once we get some solid direction on the mockups, only then will we develop the platform.

This process has taken six months already. In six months of working on ribl, we were able to build, launch, and promote both iOS and Android apps.

I’m not worried how long this takes, though. I’m more worried about truly learning about customers’ problems and ensuring that we’re building something that they really need and want.

Even then, I know I might be wrong and ultimately fail.

Regardless, I’ll feel better knowing that I took the right approach.

Conclusion

Customer development is so important, especially in the early stages of a startup.

I made a bunch of bad mistakes in the past, and I’m hoping that by applying the techniques and process more thoroughly and completely, I’ll avoid the fate of those mistakes with WinOptix.

How are you using customer development, and what has worked and what hasn’t? I’d love to hear from you in the comments.

Alignment with Co-Founders – Lessons Learned From Past Startups Pt. 2

Last week I wrote about how aligning your idea with your current life situation, skills, and interests is really important.

This week, I’m going to talk about about how important it is to be aligned with your co-founders, which may be the most important aspect of your startup.

Man, have I learned some lessons here.

Mistakes with Dokkit – Getting Married Before Dating

My first startup was Dokkit, a smart calendar app where you can find your interests (e.g. the New York Yankees or the 9:30 Club) and easily download their event calendars to the calendar of your choice.

Dokkit didn’t get very far because the co-founding team wasn’t aligned at all.

This was completely my fault, because I recruited three engineers to join the team really quickly, and we didn’t take the time to feel each other out.

In essence, we got married before dating.

This led to a number of issues.

First, we had different work styles that didn’t mesh at all.

Next, all of the engineers had full-time jobs, while I was primarily working on Dokkit. So our schedules and time commitments didn’t align.

Finally, we just had different visions of what Dokkit could be.

It’s no wonder why Dokkit never got anywhere.

After Dokkit and Ribl

After we stopped working on Dokkit, I wanted to make sure that I had a strong relationship with anyone I might work with as a co-founder in the future.

My next co-founder would be Jeff Thorn, the CEO of Thorn Technologies, whom I worked with on ribl. I consulted for his company (and am now its CMO) for a couple of years before started ribl. So I knew that we worked well together, and we still do.

We launched and grew ribl, and it came and went. Oh well.

After we stopped working on ribl, we worked on deciding what our next startup project would be.

After almost a year of tossing around ideas, we couldn’t agree on anything.

Why not? I think this is where our alignment, or lack thereof, came into play.

I was more interested in products in the marketing and sales space, since that was where my expertise was strongest. He and the rest of the team were more interested in building tools for coders, since that is who they are.

I had a bigger appetite for risk. I could go a few months without a paycheck, while Jeff could not.

I wanted to move faster and dedicate more resources to launching a product. Jeff had a services business to run.

So while we’re still working together at Thorn Tech, we’re no longer working together on a startup.

Conclusion

Bottom line is that you gotta have alignment with your partners.

Do you work well together? Do you want the same things? Are you willing to sacrifice the same amount of time, money, and sanity? Are you on similar timelines?

If one of you wants to build a company that grows really fast while the other wants a lifestyle business, it ain’t gonna work.

If someone wants to sell the company within 5 years while the other wants to build a generational company, it ain’t gonna work.

If one wants to risk it all while the other is more conservative, it ain’t gonna work.

Founder alignment is so important. So don’t rush into getting married with a founder. Take the time to make sure you work well together and are aligned on most if not all of the aspects we discussed.

I’ve made multiple mistakes here. Learn from me and avoid these gaffes!

Have you had co-founder alignment issues like I have? I’d love to hear your story!

Lessons Learned from Past Startups – Alignment with Idea

 

Align_center_font_awesome.svg

As I’ve worked on my startup WinOptix, I’ve thought a lot about the mistakes I’ve made in my past startups and how I can avoid making those errors again. So I figured I’d write a few (or many) blog posts about my lessons learned.

The first lesson I’ve learned has to do with how to select an idea or space that you’re properly aligned with.

The mistake – ribl

The first big mistake came on my second attempt at a startup, ribl.

ribl is a location-based messaging app, something like a localized Twitter. We were chasing the SoLoMo trend – Social, Local, Mobile – which should have been a red flag right off the bat.

For apps like these, network effects are super important. The more users you have, the more value your app provides. Think about social networks like Facebook or even the fax machine (if you’re old enough to know what that is). The more users on each platform, the more people you can interact with on the platform or with the tool.

In ribl’s case, the more users we have, the more content would be posted by these users, and the more value new users would get from interacting with this content. And so on and so forth.

So you really need to dedicate a lot of time to growing your user base very quickly to achieve these network effects.

But my co-founders and I were primarily working on growing Thorn Tech, a software development services agency, for our day jobs. Thus, we weren’t fully dedicated to ribl and couldn’t focus enough time to iterating the product and growing the user base.

Even though we built a great mobile application, the business model of ribl was just too dependent on the number of users. We wouldn’t have been able to monetize ribl (with advertising) until it had millions of users, and we couldn’t dedicate enough time nor move fast enough to feed that beast.

Essentially, the idea of ribl wasn’t aligned with our current situation and the amount of time we could dedicate to it.

Applying the lesson learned to WinOptix

After we decided to stop working on ribl, I realized that the next startup I worked on had to really be aligned with my life situation, interests, and expertise.

I’m still working with the guys at Thorn Tech on the agency but we aren’t pursuing a startup together anymore (more on this in a future post). So I’m still in a similar situation where my startup is a side gig, and I don’t have enough time to dedicate to growing a consumer application.

This definitely factored into the industries and products I would pursue and how I decided to work on WinOptix.

WinOptix is a platform for government contractors to make better sales decisions, so I’d be selling to businesses instead of trying to grow a massive consumer user base. I’ll still have to move fast and dedicate a lot of my time to growth, but it’s a much more measured, sales-based approach.

WinOptix also has a clear, revenue-focused business model. It’s a software-as-a-service (SaaS) application where future customers will pay a monthly or annual fee for the software.

So I can monetize with a single customer, as opposed to needing millions of users to start earning revenue.

While getting one customer will still be very tough, this situation is a much better fit with where I am in life. In addition to working on the startup part-time, I’m a bit older with a family, so the consumer app revenue model just doesn’t jive.

Also, the subject matter of WinOptix is more aligned with my strengths. WinOptix is a sales, business development, and analytics tool, three subjects that I’ve been intimate with for all of my career. And even though I haven’t worked in government contracting, I’ve been able to understand the industry and identify problems through over 40 customer development interviews with experts in the field.

Overall, WinOptix is a completely different business that fits my situation much better than ribl ever did.

Conclusion

The alignment of your idea with your life situation, interests, and expertise is extremely important.

I’m not saying that your idea needs to perfectly match all aspects of your life and career. If you find a problem that you’re super passionate about that doesn’t quite align but you think you can make it work, by all means get at it.

But I’ve made this mistake, and this lack of alignment was one of the primary reasons why ribl failed. If we had the foresight to see this misalignment, we may have been able to use that time and effort on a concept that fit us better.

The next time you’re thinking of an idea or space to pursue, consider the alignment of that idea with your current work and life situation.

What are your thoughts on alignment of the idea with your situation? I’d love to hear what you think in the comments.

Should you work on your weaknesses or focus on your strengths?

I recently listened to an episode of the podcast Seeking Wisdom where David Cancel and Dave Gerhardt from Drift talked about why you should forget about your weaknesses and focus on your strengths. Read the blog post here and listen/watch the video at the end after you finish reading this post. :)

This point of view certainly makes sense. It’s frickin hard to learn or get better at something that you’re not good at. And because it’s hard, you’ll also get frustrated when you make slow progress.

So maybe that time would be better spent on focusing on your strengths so you can turn them into superpowers, and delegating the stuff you’re not good at.

Here’s an excerpt from the episode’s blog post about one of David’s weaknesses:

For example: I’m not great at following up (especially with email). I’m a momentum maker. And that means I’m better at focusing on the here and now than I am at staying organized and creating process. But I used to fight it and I would focus on every single hack and trick to try and help — from to do lists on my laptop, reminders on my computer, phones on my phone, notebooks, etc.

This lesson took me a decade to learn. But eventually I learned the secret: I needed to double down on my strengths and surround myself (and team) with people who complement my weaknesses.

As a non-technical startup founder, it would be faster for me to recruit a technical co-founder or a contractor to help build the app. So instead of learning how to code, I could focus on customer development, marketing, and sales, all stuff that I’m much better at doing.

I do think there are situations where spending time on your weaknesses makes a lot of sense.

High-leverage activities

The first is if that weakness is a high-leverage activity that will have a substantial benefit if it’s improved.

In David’s example, being good at responding to email is a positive trait to have. But is it a high-leverage activity? Is it worth spending a decade trying to figure out how to get better at it? Or can David easily hire someone to help him respond to emails and be more organized?

On the other hand, for my situation, coding is a high-leverage activity that would benefit me greatly to know how to do.

Software developers are tough to recruit, but I was able to snag one on a contracting basis to help build WinOptix. Things are going great, but what if he decides to leave? I’d be shit out of luck.

And if we continue to work together, understanding how to code will allow me to 1) better estimate how long it will take him and others to build features of the product, and 2) contribute to the development of the product myself (eventually).

If your weakness is a high-leverage activity, it might make sense to put in the time to improve it.

If you don’t really like your strengths, enjoy working on your weakness, or both

Let’s say I’m strong at marketing. But one day I just get sick of writing blog posts, promoting them, running paid ads, and all of the other tasks that marketing entails. What should I do then?

The first thing I should do is assess my career. But what next? Should I continue working on my marketing skills, even though it kills me inside?

And let’s say I’m weak at programming (I am), but I looooooooove it (I don’t. It’s aight, but I don’t know enough to love it yet). Should I not try to improve my coding skills, just because I’m not really good at it?

Or what if both were happening at the same time?

Focusing on my strengths certainly wouldn’t make me any happier or necessarily better at my job.

Over to you

While I do see David’s point, there are certain situations where shoring up your weaknesses might make sense. I think the decision will be unique to each individual’s situation.

What’s your situation like? Are you focusing on your strengths, or working on your weaknesses? I’d love to hear from you.

BTW, David Cancel was an awesome guest on my podcast. Thanks David!

Successful products are either loved or needed. How about both?

Slack quote

Ted Leonsis has said that a successful product is either loved or needed.

Your electricity provider is needed.

Your Honda Civic or Toyota Corolla is needed.

Airlines are needed. They certainly aren’t loved right now.

Snapchat is loved but not needed.

Medium is loved. We didn’t really need another blogging platform, did we?

Tesla is loved; you really don’t have to spend that much money on a car to get you from point A to B.

The magic happens when your product is needed and loved.

Companies like Southwest, Slack, and T-Mobile have cracked that code.

Southwest has created a culture where they treat their customers well and make flying enjoyable.

Slack has built an amazing enterprise communications product that everyone is addicted to.

Even though its cell connectivity isn’t the best, T-Mobile just keeps coming up with ways to lure its competitors’ customers away and keep current customers around.

Even if your product is boring and unsexy, there are many ways that you can make it both needed and loved.

Add some personality to your microcopy. Make customer service central to your companyBe transparent.

There are plenty of ways to achieve both.

How are you making your products and services both needed and loved? I’d love to hear from you in the comments.

The life of a startup founder – when little things are big deals

Head in Hands

Here’s a little story about how warped my brain is from entrepreneurship, the roller coaster ride that being a startup founder is, and how my idea of a “win” has drastically changed.

Over the last couple of months, I’ve been doing customer development for my startup, WinOptix. I’ve spoken to over 30 government contracting business development folks to learn about their problems with the BD process and pitch my concept to get feedback.

I learned so much about the government contracting industry and received a ton of great feedback.

And to my surprise, one of these interviewees (let’s call him Victor, not his real name) said that he would pay to have a tool like WinOptix built!

(Yes, I definitely got excited about this at the time, but that isn’t the situation I’m writing about in this post.)

I told Victor I would get back to him soon. I hadn’t even incorporated the company nor did I have the ability to build the product, so I had to get to work on both fronts before moving the potential engagement forward.

At the same time, I was setting up my new WinOptix email address with Google’s G Suite. I emailed Victor from that new account.

Usually I would set up email forwarding to my primary email address so I can manage everything from one account and not have to check multiple inboxes. Except I forgot to do so this time.

Of course, Victor emailed me to set up a time to chat about moving forward soon. And I didn’t receive the email until I checked my WinOptix account much later. UGH.

I replied with an apology. No response. I emailed him again. No response. And again. No response.

I was totally bummed out that I might have missed out on the first paying customer because of a stupid email setup mistake. This could have been huge for WinOptix, and I just banged my head on the wall about how dumb I was and how I screwed up a massive opportunity.

I couldn’t stop thinking about my screw up and how I might have missed out on my first customer. I actually had some trouble sleeping and was down on myself for a while.

After a couple of weeks, I made a last-ditch effort and gave Victor a call.

To my surprise, he picked up the phone! He said he saw my emails and was planning to respond, but had been so swamped that he didn’t have time. And he said he was still interested in working together on the product, and will reach out soon.

I was ecstatic, just because of a simple phone call.

I didn’t even get a firm commitment, but the simple fact that the potential deal was still alive and that I didn’t totally screw it up was a big win to me.

I thought about how this situation – an email setup snafu, a missed email, then the redeeming phone call – is such a small, insignificant blip in the big picture.

But the impact that it had on me was profound.

Then I thought about a couple of things:

  1. Is this relatively small situation having such a major impact on my psyche a good thing for me?
  2. Is my reaction to this situation a telling sign of my ability to be an entrepreneur? Do I need to be more even keeled and steady, and not get so high when good things happen and so low when bad things happen?
  3. Do other early-stage entrepreneurs feel the same way?
  4. What does this situation say about my attention to detail?
  5. If I worked for a larger corporation, what would be an analogous situation, and would I feel the same way?

I’ll write more about these thoughts in future posts. To be continued…

What do you think about this situation? Did I overreact? Have you been through something like this – where a small situation has a profound impact on you? I’d love to hear your thoughts.

Photo courtesy of Alex Proimos on Flickr

When patience and perseverance can be bad traits to have

Patience and perseverance are excellent traits to have. But in certain situations, you don’t want to wait too long, or endure for too much time.

I wrote a post a while ago about how raising a kid is like running a startup, and I find that patience and perseverance can apply to both as well.

Being patient with your child is a virtue.

There will be times where your kid throws tantrums and just does things that she shouldn’t be doing. Over and over and over again. Or if you’re sleep training your kid and she just cries and cries and cries and sounds like she may never go to sleep.

And you might lose your cool.

Being patient, persevering, and teaching your child the right thing to do – over and over and over again – will make her better understand right from wrong. And letting her cry herself to sleep, even though it might be painful to hear, will be better for everyone in the long run.

Patience can help your startup and business succeed as well. Software-as-a-Service (SaaS) investor and expert Jason Lemkin says it typically takes 7+ years to truly build a SaaS company. And many founders give up too soon.

It takes some time to learn what you need to learn and do the things you need to do in order to be successful. At least that’s what I keep telling myself.

But when might too much patience and perseverance be a bad thing?

In the sleep training example, maybe your kid is crying for a different reason other than just not being soothed to sleep. She may have poo’d or pee’d, maybe you forgot to give her favorite sleeping toy to her, or it might be too cold in the room. If too much time has passed and she still isn’t sleeping, you should probably go in and check on her.

In the startup world, you have to realize when it’s time to jump ship. You might recognize that the founding team isn’t right for you, and it makes sense to split up. Maybe you see that no one really needs or wants your product, and it’s time to pivot to another idea.

In these cases, you might be wasting your time pursuing things that just aren’t going to work, and the best solution is to not persevere and just move on.

Overall, patience and perseverance are great characteristics to have. But the tough part is recognizing when they are detrimental to your particular situation.

The uncertainty of launching a startup product

compass

When you’re building a product for your very early stage startup, there will always be uncertainty. The weird thing is that it can come in different forms.

I’ve been part of building two startup products, even though they didn’t get very far. One was a smart calendar called Dokkit and the other is ribl. In both cases, I could envision exactly what the product would look like from the jump.

The uncertainty in Dokkit came when our team couldn’t quite agree on the product vision after building the alpha version. Everyone had their own ideas. We didn’t talk to enough potential users and didn’t validate what we needed to build. The end of Dokkit came shortly after that.

With ribl, the uncertainty reared its ugly head when trying to acquire customers after product launch. Again, we didn’t do enough to validate the concept, primarily because we had such a clear vision of the product and we were absolutely enamored with the idea. Big mistake.

Now I’m working on WinOptix and have spoken with a bunch of government contractors about their business development processes to thoroughly test the validity of the concept before building anything.

And unlike Dokkit and ribl, the ambiguity now comes in the form of not knowing what to build.

I’m hearing some excellent feedback about the government contracting BD world and the multitude of problems that exist. And one of those problems aligns with my initial hypothesis of what WinOptix might do.

But are the other problems mentioned bigger issues for my potential users?

Have I truly validated anything?

When do I start building something?

And what the hell do I build?

All of this uncertainty is stressful. I might make the wrong choice and waste time and money building something no one wants. That’s a startup killer.

But it’s exciting, too, because I’m confident that there are problems to be solved here. It’s just a matter of finding out which one will have the most impact. And it’s just more interesting than any other problems I’ve faced in other jobs. :)

Uncertainty is inherent in startups, and it can come in all forms. But that’s the exciting part, and I can’t wait to find my way through it all.