Having built a field management system in the construction industry[1], I can confirm, it's a tough market. And, most of it comes down to getting in front of people. A lot of my time is spent going to trade shows and pitching, just like Tracy did, when I'm not coding.
There's a stigma that this industry is full of people who resist technology, but I really don't think that's the case. People in this industry resist change because change is risky. There's too much money at stake, and delays associated with new technology can ruin an entire job. Paper processes are usually terrible, but you're never going to have to battle wi-fi connectivity to flip through your spec, or experience your pencil throwing a 500 when you fill out a safety analysis. It takes a while for anyone in the field to get comfortable with the pros and cons of a new process versus a paper process that's worked for years.
It's changing incredibly quickly, though. There's a lot of new products getting funded, and a big opportunity to integrate between them.
Exactly- risk aversion is the driving force. When I was a civil engineer, paper was king. It's wasteful printing 5x copies of one 1000+ page spec, but it's reliable.
I did write a shop drawing automation program when I worked at the office. There was resistance to it at first, but getting the right people on board and demonstrating the improvements helped a lot to get it all the way to the executives of the company. During my push to get my software adopted I learned a lot similar to your perspective; many professionals don't dislike new technology, but they're unwilling to put their name beside it unless it's proven to work.
A lot of young engineers like myself want to walk in on the first day and start shaking things up. But working in a slower, more risk averse field has made me a better software engineer by tempering some of those impulses to adopt the latest and greatest tech. Taking a pragmatic and proven route will nearly always get you reliable and predictable results.
>A lot of young engineers like myself want to walk in on the first day and start shaking things up. But working in a slower, more risk averse field has made me a better software engineer by tempering some of those impulses to adopt the latest and greatest tech. Taking a pragmatic and proven route will nearly always get you reliable and predictable results.
Nice to see your perspective, this is gold! I've worked in the B2B and risk management side of Construction and I'd like to chime in - as a verification - of the market in Construction. It's a multi-billion dollar per month industry in every major City. Property and development and investment are where big money plays. REITs and up.
Two things Construction cares about: Safety & Shrink.
Safety in the human cost of skilled labor - and settling workplace claims of deaths on the job / innocent bystanders / loss of property (on and on and on) - is a giant consideration. Claims are more expensive than, well, anything because they're unpredictable. Can technology help? Yeah, but looking at a tablet ain't gonna do it, unless it's like 30 cameras on the job site...which leads to...
Shrink. That's what it was called in the Big Box store. Losses due to theft. It could be something small, or something kind of big. Or maybe somebody on the job site tipped off a local relative with a good crew who have the brass ones to haul off a couple generators if they're not lifted up on a crane over the weekend...again, there's a nice middle ground of disruption for technology, but it has to be grounded in real world learning.
Sketching out a few ideas on a white board will probably not be anywhere close to the 3 years I consulted with Field Safety Managers, Claims Managers, Managing Directors who speak at Conferences to this day...I was the guy who could write it down, put it in images, because Construction people have their own world.
I'll never forget one story a highly accomplished team leader said on a conference call about Safety: "Last week at the new XXXX auto plant, installing a 4 ton brace that was freshly painted, the crew was so worried about scratching the paint that one got jammed between the brace and the wall and lost his life. Priorities are our concern."
TL;DR: Nobody makes a good brisket in a microwave.
I agree with your thesis and would like to anecdotally expand on your second point. It's been my experience that people in the construction industries -- and I say this as someone who comes from a multi-generational family of builders -- tend to be on the leading edge of technology adoption.
For example:
- Quick adoption of pagers, cell phones (originally the physically installed "car phones", later, Motorola's "brick"), Sprint's "Direct Connect", to now using iPhone or Android-based devices for on-site visual status updates.
- GPS and RFID vehicle, inventory and tool tracking.
- Computer-assisted design (CAD) and manufacturing (CAM).
Not to mention all sorts of back-office software and tools.
All of these things need to be vetted in light of risk mitigation, as you stated. Most builders I know have been burned multiple times in the past when tools and processes fail, so they tend to hesitate before jumping to the "next-greatest-thing-ever".
> People in this industry resist change because change is risky
I'm researching a similar field, where risk of change is the biggest barrier to improvement. What have you been doing to combat this / how do you reduce the risk? What makes a user willing to take the jump?
Early on, it's meant spending months on implementation, hand-holding the first few users so they can become evangelists within the company. It's not a lot of work, it's just over a long period of time.
I track usage metrics every day and routinely message power users to ask what may be keeping others from adopting, asking non-users if they've been trained, and asking execs if they have evangelized from the top down.
So, you have to hit everyone over a long period of time.
The company I work with gives everyone a verizon cell hotspot and an android tablet. These work fine in city areas where this company does a lot of utility work.
But, when you do an install of electric wire towers on a mountain, you might not have cell connectivity. Most apps get by this by saving data locally, and then transmitting on the next connection.
Well of course remote work is going to have its own challenges, but I don't get the feeling that that's what's going on here. So, besides corner cases, is there any reason not to consider cellular tablets in the construction world?
Job sites, especially those in the throes of major structural construction, are a horrible place if you are seeking consistent wifi or cellular coverage.
Generally: The thick concrete walls, exposed rebar, and intentional and unintentional geometric structural elements combine to form a giant Faraday-esque electromagnetic exclusion zone. Even with wifi repeaters on each floor you aren't assured a connection.
I worked for LATISTA as a product designer and spent a significant amount of time on-site speaking with users about this exact problem. It's getting better, especially with the larger construction management / development firms, but it's not a solved problem (unless your firm spends a significant amount on portable IT infrastructure).
I guess my point is that there are some crews where all their work is remote and subject to spotty cell service. It all depends on the kind of work the company is doing. So, for some companies, it's not a corner case at all, it's a factor in the primary use case.
They don't have to be "equal" in any sense. All that matters is whether they meet some (probably ill-defined) threshold of reliability. In at least some circumstances, neither does, even if cellular gets closer.
That's terrible advice. It worked out in their case and we get to hear their story, what about the people who did this and failed? Don't extrapolate what worked for them into generic advice, to say the least, it's dangerous.
I'd probably roll this advice back to the more general case of "don't be afraid to spend money to acquire the first users". The PlanGrid team may have done this by maxing out credit, but that's just one (and possibly the most risky) way to do this.
My first concern would be display resolution: A blueprint is big, and mobile displays are small. How the heck to see a big blueprint on a small screen? Maybe use some very high resolution funny glasses -- but the OP didn't hint at any such thing and, besides, wanted the mobile devices to cost less than $100 each.
The product design work, that is, go to the customer, e.g., if trying to help truck drivers, then ride with some truck drivers and maybe get a job as a truck driver for a while, is old advice in operations research.
The material on thinking about and planning whom to approach, understanding what to tell them to get their interest in under two minutes, etc. is good industrial selling.
The article describes for the product planning a lot of worker hours and expenses for travel and lodging: Sounds like PlanGrid burned a lot of cash before they got much revenue.
Sure, I thought of zoom. My concern, having drawn and looked at some blueprints, was that a lot of zoom would have the person lose sight of the big picture and that there would be no substitute for a big screen with a lot of resolution.
Okay, if I'm wrong -- good for PlanGrid.
Amazing that they were profitable in the first year -- good for them. That was likely, I'd guess no doubt, tough to do.
People did hook up to large TVs, use the website with a big monitor, etc.
The mobile app is about being able to look things up and input data right there next to the problem you're dealing with.
Construction is odd in many ways. The superintendent is more powerful than the CEO. If he/she doesn't want to use your software all the IT mandates in the world can't make him/her. Big construction companies are one major fuckup away from bankruptcy at all times. The superintendent is only as good as their last job and can make the difference between a profitable year and a money pit of lawsuits.
Have you tried selling a new, unproven product to an entrenched industry like construction? I have, and it's much harder than refactoring spaghetti code or learning Haskell.
>To bring them into the fold, the team started running superintendent “Ask Me Anything (AMA)” sessions at the office, where the two goals were to celebrate them as experts in the field, and to learn as much as possible about their lives, work and problems.... During these events, the superintendents got to know individuals at PlanGrid too, and walked away bigger evangelists than they were before.
I haven't seen this done before, and it's a great idea.
There's a stigma that this industry is full of people who resist technology, but I really don't think that's the case. People in this industry resist change because change is risky. There's too much money at stake, and delays associated with new technology can ruin an entire job. Paper processes are usually terrible, but you're never going to have to battle wi-fi connectivity to flip through your spec, or experience your pencil throwing a 500 when you fill out a safety analysis. It takes a while for anyone in the field to get comfortable with the pros and cons of a new process versus a paper process that's worked for years.
It's changing incredibly quickly, though. There's a lot of new products getting funded, and a big opportunity to integrate between them.
[1] http://safety.voyager.vc/