If you enjoyed this post, share it.

If this is your first time reading, I recommend you start with a new B2B SaaS venture and table of contents of biweekly posts for the past six weeks.

tl;dr The past two weeks have been absolutely nuts. I had strong internal struggles of whether or not to continue (and what my next steps were), entertained a couple software ideas before choosing a potentially viable software idea and attended an industry hackathon where I met my technical cofounder. 

It’s been a little surreal how emotionally draining this period was — truly a rollercoaster. One day I was ready to (temporarily) give up, and the next day I made a fateful phone call and got fired up and reinvigorated.

So much of surviving startups is your mental resilience and resolve. You are your most important cheerleader; moreover, the buck stops with you — no matter how many people you ask for advice: you ultimately make the decisions and are responsible for your actions.

If you don’t believe in yourself or your startup, no one else will — and it will clearly show. It will teach you about yourself and your character about how you can handle making important decisions in the midst of uncertainty and risk.

I. Strong internal struggles
II. A fateful phone call
III. Domain expertise and narrowing my scope
IV. Importance of being agile over water fall
V. The AEC Hackathon (March 14-16, 2014)
VI. Finding a technical cofounder
VII. Choosing a potentially viable software idea
VIII. Highs and lows these past 2 weeks
IX. Lessons learned

When a startup launches, there have to be at least some users who really need what they’re making—not just people who could see themselves using it one day, but who want it urgently. Usually this initial group of users is small, for the simple reason that if there were something that large numbers of people urgently needed and that could be built with the amount of effort a startup usually puts into a version one, it would probably already exist.

Which means you have to compromise on one dimension: you can either build something a large number of people want a small amount, or something a small number of people want a large amount.

Choose the latter. Not all ideas of that type are good startup ideas, but nearly all good startup ideas are of that type.

– Paul Graham, How to Get Startup Ideas

I. STRONG INTERNAL STRUGGLES

I won’t lie, I was very close to looking for a full-time job at a fast-growing B2B SaaS company (or even a job at a construction company, as I talked about the question of domain expertise before) and working on this venture on the side.

And I’ll be completely honest (for better or for worse), I’m not sure if this is completely off the table just yet. But for now, given recent important events of finding a technical cofounder and a potentially profitable idea (more on that later), I am interested to first see how things will play out.

Find a job at a fast-growing company and build your network
I consulted some friends who are far more experienced than me and also have gone through startups of their own about my situation (at the time) and they all told me the same thing: find a job at a fast-growing company and to build my network; you can always just work on this on the side.

How else will you find a technical cofounder? How else will you learn how to find product-market fit? How else will you learn how to acquire customers? How else will you learn about growth, marketing and distribution? How else will you learn _______? etc.

The first time a friend (who did his own startup before working for one now) told me this was a month ago. I got really excited and completely agreed with him.

I said, “You’re absolutely right.”

My parents had been telling me the same thing for months, but for some reason I didn’t take their advice seriously, since they do not have a tech background at all or knowledge of startups. Go figure.

…I was super ready to find a job. That night, I spent 4-5 hours doing research and putting companies in a spreadsheet that fit what I was looking for and places where I would learn the most to equip myself for my own B2B SaaS venture.

I called my parents and they were delighted to hear this new development.

“That’s the best news I’ve heard all year,” my mom excitedly said.

And then I changed my mind
However… the next day I woke up, thought about it some more and completely changed my mind.

Was it really necessary to join a company to find a technical cofounder? What exactly was I trying to do and learn? Would it help me in an early-stage, pre-product-market fit environment?

That was a bit debatable. But you could think of it as building future founder/CEO skills… right? Hm. There’s no right answer here and I wasn’t entirely sure I should give up just yet.

So I spent the next two weeks continuing my customer research…

Then, earlier this week again — I went to Square for an event for women entrepreneurs and caught up with a friend at Square who went through three of his own startups and asked for his advice.

He said the same thing. It was one of the things he regretted not doing.

You should find a job at a fast-growing company and build your network. Trust me *gesticulates for emphasis* on this.

I said, again, “You’re absolutely right.”

And back to the spreadsheet I went that night… with different companies now.

Two hours later, I texted him and other friends about my decision to look for a job. Wow! Good for you, they said. You’re doing the right thing, Melissa, others read.

So many smart friends were telling me the same thing… I thought, they must be on to something! And I should listen to them because I don’t know what the hell I’m doing.

But I knew myself — as this wasn’t the first time I heard that advice — and was scared I’d change my mind the next day again.

II. A FATEFUL PHONE CALL

I was just about to acquiesce and start talking to companies I was excited to work for, until a fateful phone call stopped me.

Taking the day off to think at Point Reyes
After hearing that advice again, I wanted to really make sure I was going to make the right decision and not just do a 360 to change my mind the next day.

I decided to take the next day off and just go to the beach by myself and think about things. I drove two hours to Point Reyes national seashore in Marin County and spent 4-5 hours just walking on the beach, accompanied by my music, earphones and a bottle of red.

I’m going to do it, I decided. I’m going to work on this on the side while working for a fast-growing B2B SaaS company.

Alright, I thought when driving home, I know what I gotta do now.

A fateful phone call
One of my leads (a commercial steel inspector) and I did extensive email tag for the past four weeks, to the point where he became irritated with me about how difficult it was to get on the phone so I could ask him follow-up questions on his survey answers.

He called me the day I was at the beach, which I didn’t answer; but because I just wanted to talk to him and get our conversation done so there wouldn’t be more email tagging and ill will between us, I called him the next day at noon.

He picked up the phone on the first dial.

We then talked about the inefficiencies in his workflow, as well as a well-defined problem he had and a well-defined software solution he had in mind.

A lightbulb went off in my head.

I think I found my software idea,” I thought. “This is it!!!”

The problem he mentioned wasn’t the first time I heard about it, but the first time I could possibly think of a concrete software solution for it — and it would not only be for inspectors like him but for general contractors to generate punch lists, etc.

If this app existed, I said, how much time would that save you? “Easily 2 hours a day, at least.”

Wow! That’s easily 10 hours a week and 40 hours a month…

I could see this definitely work… and I guess, the gears were turning in my head that I could possibly charge $100/month easily for software that would save someone 40 hours of work each month.

Right?

I then became super excited and reinvigorated and began to start emailing other leads to potentially validate this solution.

Later on, I found out that PlanGrid (a YC-backed company, believe it or not) actually solved this problem and more. They were the main competitor in this space and they have an absolutely amazing product, team and growth rate; I was a bit stuck on how I was going to dramatically differentiate myself. 

Later on, I decided to ultimately ditch this software idea in lieu for another one for other reasons as well.

III. DOMAIN EXPERTISE AND NARROWING MY SCOPE 

The question of domain expertise
I want to revisit the question of domain expertise that I mentioned last time, because it is very critical to think about and have a plan of attack in terms of market penetration, building credibility and establishing rapport with customers in the industry.

A friend and I were discussing what I would be doing and what kind of help I would need to do a B2B SaaS venture in construction as someone who is non-technical, despite having a product manager background and more critically, non-industry. In spite of what I could do in terms of user acquisition, prototyping/wireframing, sales/marketing, etc. there were two critical areas where I needed help beyond my own capabilities.

I would need to recruit 2 key people in order for this to work:

  1. An industry person who knows what features to include, how user interactions should work, etc.
  2. A software engineer who is actually interested in this problem and to actually build it

It’s difficult enough to find a technical cofounder, not to mention a cofounder in general… much less recruit two people who don’t necessarily need me to move forward to build a B2B SaaS software app.

Since this is rather difficult to accomplish on my own, especially at this stage, I was thinking I should try to compensate in one or the other categories above: I can either learn how to code myself (and this could be a great project for me to learn to ship myself via code) or get a job in the industry so I can witness first hand any inefficiencies where software could help solve.

Decisions, decisions.

Would it be better to learn how to code or get a job in the construction industry?

I talked to several engineer friends and they all agreed industry would be better: even if I could code, I would need a good idea too. I would learn infinitely faster working in the industry about construction, whereas my rate of learning with regards to coding would be slower and not as “unique” so to speak.

It’s a lot harder to get a good idea than to learn how to code, and to have a good idea, I need to understand the industry. Plus, I could learn how to code on the side.

But don’t do it as a full-time thing, they said. If I was going to do it in the first place.

Hmmmmmm.

Narrowing my scope
After talking to a good deal of construction professionals, I heard many of the same problems over and over.

Ultimately, I decided to narrow down to four key areas (this is by no means exhaustive of all problems in construction, believe me, but just the areas I could narrow to possible good fits for me):

  1. Bid management
  2. Accounting
  3. Project management
  4. Field operations

I’ll briefly talk about each area and why I’m excited (or not) about it.

(1) Bid management
I am most enthusiastic about bid management, because there is really one incumbent player in that space and I feel that I could probably do a much better job (once I also partner with someone in the industry). I also understand the process behind this.

Interestingly enough, one of the people I met at the AEC Hackathon recently raised money for his own bid management app. Very interesting.

(2) Accounting
Not a big fan of this, as construction accounting is extremely technical. But there aren’t a lot of solutions out there beyond ERP solutions that are very expensive, not to mention bulky. A lot of small players usually opt for Quickbooks, while bigger players will choose an ERP solution. There isn’t quite a middle ground.

(3) Project management
Collaboration and communication will eternally be a hassle for everyone in construction, because there are SO many players and moving parts. Think about trying to build a hospital, not to mention a custom home. You think building a software product is hard? Think about how hard it is to collaborate and communicate with many internal and external stakeholders in big commercial projects and even residential ones (to a smaller extent). Oh boy, I’d get a headache just trying to think about all the moving parts and everyone involved.

I don’t like this area as much, because it is extremely saturated and there is not a clear way to deliver unique value. Not even to mention a construction-specific project management software, but just project management software out there in general — JIRA, Asana, Trello, Basecamp, Producteev, the list goes on and on.

It reminds me of CRM’s — there are millions on millions of CRM software out there.

Project management tools are also inherently social, and you will have to face problems of convincing your end users (all of their different roles — architects, field personnel, people in the office, etc) to use it. Before that, you have to convince them they’d save a lot of time and money before you can convince them to fork some money over to you to buy a product that they can’t solve using some janky, ad hoc methods with email, Excel spreadsheets, etc.

Yeah, it’s not something I’m that excited about.

(4) Field operations
This one is very interesting. This is the area of biggest “disruption,” so to speak (as much as I hate the word “disrupt”) — but also the area of biggest challenges. Field personnel are typically the most un-tech savvy folks you’ll find in construction, and so even if you make the best, easiest to use, well-designed software, it will be an uphill battle if you can’t get your end users in the field to use it.

The problem of field operations is that you’re not only trying to solve problems with software, but also trying to change habits and affect behavioral change.

These grizzled, older generation men in construction who have been working in the industry for 20-30 years will wave dismissively at you and your “little app” and say they’ve been doing this for years and don’t need some app to help them. They probably don’t even own smartphones or tablets (at bigger commercial GC’s, you will find more forward thinking field personnel) and the steep learning curve of learning technology may take more time to train them than for them to actually do the job.

The irony kills me. Right?

PlanGrid is doing an exceptionally well job of being an app for field operations, but just because they are solving one specific problem very well in field operations. Fieldwire (from AngelPad) is also trying to be a PlanGrid but also integrate some project management into it as well.

At this point, I was strongly considering getting a job in construction (or even part time consulting) to really study a company’s bid management processes to start working on a bid management app.

IV. IMPORTANCE OF BEING AGILE OVER WATERFALL

I want to especially stress this as one of the most important lessons I learned these past 2 weeks.

It is more important to be agile over a water fall model, which is a more sequential design process.

When I say agile vs. water fall, I am referring to the style of my customer outreach strategy and research.

I am very process-oriented and perfectionist in this regard — if I don’t do exact steps in my process or am in the right environment, I often don’t do it at all or procrastinate on it. For example, I had a strong belief that I had to send prospecting emails out by early morning but for some reason kept sending them in the afternoon — so I just didn’t send emails at all for several days because I couldn’t grok my schedule/habits to send them early morning.

I had this water fall belief that I had to absolutely make 50+ phone calls/meetings before I was able to target a profitable software idea — but was actually up to 24 phone calls/meeting when I took that call with the inspector and got that software idea.

I had this water fall belief that I had to absolutely make 50+ phone calls/meetings before I was able to narrow my scope within a company — but was actually up to 17 phone calls/meeting when I began to take note who in the companies were the most useful to talk to and could provide the most value in our conversations.

I had this water fall belief that I had to absolutely talk to everyone in a construction company — but as I learned more about roles and types of companies, I realized it was better to become more targeted in who I wanted to talk to (only the estimator, or only the project manager, etc).

What am I trying to say?

You will learn things as you go along, new and useful and valuable tidbits of information that you didn’t know before.

Learn to be agile.

Take these things into account and tweak your strategy/approach accordingly. Do not blindly follow an approach you laid out in the beginning for yourself (just because you read somewhere someone did the same and it worked for him, etc), if new developments and knowledge are persuasive enough for you to become even more targeted and specific.

Does it really matter how many phone calls you make? No.

Does it really matter if you actually find a profitable software idea or not? Yes!

Sometimes things take longer than you’d expect; other times, things may take shorter than you’d expect. You need to learn how to adapt and figure out how to iterate things to keep up.

V. THE AEC HACKATHON (MARCH 14-16, 2014)

So I actually met with a friend who is also a startup founder and when I asked her the question of trying to find a technical cofounder  — I’m a unique snowflake, I know — she suggested I go to a Startup Weekend or a hackathon.

I already had a cofounder hypothesis that I mentioned previously, but still hadn’t had time to implement it and test my hypothesis.

This wasn’t the first time I heard this advice, but I decided to take her advice to heart and right after our meeting I immediately went on Eventbrite and looked up hackathons.

Fate intervened and I actually saw there was an Architecture, Engineering and Construction (AEC) Hackathon taking place March 14-16, 2014 at Facebook’s HQ in Menlo Park.

I couldn’t believe my eyes.

Holy shit, I thought. This is perfect.

VI. FINDING A TECHNICAL COFOUNDER

I didn’t go to the hackathon with tremendous expectations, but more so with some trepidation and was curious to meet and mingle with other folks there in the industry. I didn’t know anyone there.

I just wanted to meet people.

I didn’t think I’d meet anyone I could possibly work with, though that would be incredibly amazing if that happened (and it did!).

It was pretty cool, considering people flew in from all over the country — and one team all the way from India to attend this hackathon. I met people who worked in construction as well as architects and even others like a geospatial engineer. Not your typical Silicon Valley crowd, for sure.

I wager less than 5% of the 100-200 or so people there had a software development background in Silicon Valley (read: B2C consumer products like me). I did meet one of the original PlanGrid team members (now working for a commercial GC) and a founder of a construction bid management app (they recently raised money, as I saw from Angel List).

Overall, it was an eye-opening experience to feel like a minority at a hackathon. Haha.

So… to be clear, I actually didn’t build anything or stayed overnight to build something to show for the demos on Sunday afternoon (though there were some very cool demos!) for this hackathon, though I did for my first hacakthon back in 2012.

My goal was mainly to meet people — and hopefully find someone in the construction industry who was interested in problems I wanted to solve with software, or someone with a software (technical) background who was interested in the construction industry.

Basically, to help the question of domain expertise I outlined above.

Ultimately, I stumbled across a project manager who worked at a well-known commercial GC based in South Bay who also knew how to code. Who would’ve guessed?!

Construction industry background, check. Now I don’t have to get a job at a construction company…

This project manager was also technical, having taught himself to code on the side for the past 2 years.

Technical skills, check. Now I don’t have to spend months learning Rails with very incremental success… 

I couldn’t believe it.

He actually built a construction project management app but was having a difficult time trying to find customers (not to mention couldn’t get his own company to dogfood it) and cycled through various cofounders himself before stagnating where he was at this point.

We got along really well and felt we had complementary skills and immediately hit it off.

We then began thinking about what we could work on together…

VII. CHOOSING A POTENTIALLY PROFITABLE SOFTWARE IDEA

I mentioned an idea involving insurance to him which was pitched to me by a high-end residential GC who I talked to over Skype last December.

When she explained this problem to me, she had a very clear idea of what the software solution would be. It would be actually very doable, I realized. So simple and basic that I could even learn to code it myself, I thought.

But I wanted to first validate it with 5-10+ others in construction before I started doing mockups and wireframes.

I’ll keep you posted, I told her.

When I told him about this problem she had, he said his office admins had often complained about the same problem and we decided that weekend to work on mockups and wireframes for this product.

I want to be clear that just because we had a couple anecdotal people who would want this product, doesn’t mean we weren’t looking for additional validation. This just meant we were onto something, since he worked in commercial construction and my friend was in residential construction — meaning this problem would be fairly construction niche-agnostic, and if both had this problem, chances are there are a lot of construction companies out there who do as well.

This software idea was extremely well-defined in scope, very feasible and potentially profitable (read: customers would happily pay for this) — transforming an arduous, manual process into something that would be quickly automated with dramatic results.

We spent Saturday afternoon working on mockups and the scope of the prototype, and actually the next day he put together a static prototype.

I was amazed at how quickly he was able to work (he actually pulled a lot of similar code from his project management app, though).

We plan to meet every week — and I will keep you posted on how things go 🙂

VIII. HIGHS AND LOWS THESE PAST 2 WEEKS

Highs

  • Taking my friend’s advice and attending an industry hackathon. Glad I took her advice, otherwise I would’ve never found out about the AEC Hackathon and thus never met my technical cofounder.
  • Finding a technical cofounder who also has industry experience. Wow. I can’t begin to talk about how serendipitous this is. I’m very open and flexible on what the product is — but just that I can work together with him is HUGE. In the beginning of an early-stage startup, it’s really all about the team.
  • Moving fast on prototyping and validating a potential profitable software idea. This is still a work in progress but I’m fairly confident we can either validate or invalidate this in the next month or so.

Lows

  • A lot of strong internal struggles in the beginning of this past 2 weeks. How do you know when to quit and when to persevere? You don’t. You never will. And you have to be OK with that, no matter how crazy and scary it feels.
  • My initial water fall process and mindset was holding me back, before I finally realized I needed to be agile.

IX. LESSONS LEARNED

  • You will experience a roller coaster of emotions — from grief of having to potentially work on this on the side to finding a potentially viable idea to finding a technical cofounder, etc. It was just crazy how things changed so quickly in the course of two weeks…and that’s OK. That’s even normal.
  • Learn to be agile, rather than water fall, in your decision-making and processes.
  • Attend hackathons if you want to find a technical cofounder — especially so you can get a better idea how well you two can work together, not just if you have complementary skills. Ideally they are in your area of concentration (like AEC was for me), but that may not always be the case.

So that also means I accomplished one of my 2014 goals of finding a technical cofounder, right? 😉

P.S. I’d love to meet you on Twitter here.

And if you enjoyed this post, please consider sharing it on FB or Twitter.

2 thoughts on “Weeks #5-6: Internal struggles, choosing a viable software idea and finding a technical cofounder

Leave a Reply

Your email address will not be published. Required fields are marked *