Pat Allin and I didn’t realize that we were going to be developing a Product Strategy when we got into my car and headed up to Green Bay Wisconsin to evaluate a small internet startup, but that is exactly what we ended up doing.
Bill Eichhorn had called Pat to give him a heads-up about a small company in Green Bay for which he had done some consulting. His nose said that while things were not yet well defined, or even headed in the right direction, there might be the basis for a hyper-successful company there. He was right, company that was to emerge from our “one-day trip” up to Green Bay would be Textura.
The company that we went up to see was called (at the time) Paraclete and was focused on providing a computerized tracking system to Title companies so that they could more accurately track the distribution of escrowed funds to subcontractors against their completion of contracted steps in the construction process.
While the developers of the Paraclete software had correctly identified a need, they hadn’t asked an important question: “What would you be willing to pay for the software”? Unfortunately, the Title companies had already priced the risk of mistakenly getting ahead of construction process in their payments and were not willing to pay for the service.
Fortunately for us, Pat and I didn’t walk away. We were up there and had surprising access (Green Bay is a smaller and friendlier market than Chicago) to many of the players who might have been involved in helping to specify the Paraclete software. Not having any experience in construction, Pat and I listened to these folks and learned how they did their business. We spent time with them (doing ride-alongs, figuratively and literally) as they went through the process of selling work, sub-contracting the work it and going through the settlement and payment process.
We were shocked by the lack of rigor in the processes. Pat and I had spent a good portion of our careers working with Fortune 500 companies helping them improve their business processes and we had never seen processes in such poor (ineffective and inefficient) shape.
The one-day trip grew into weeks and then months. We became convinced that we could change the industry. But, as I said in my last post, a product strategy is more than just a generalized statement like: Our products will change the construction industry! There needs to be enough detail to allow product development to develop useful products.
Our product strategy was shaped by several observations we made during our inquiries:
- Many of the players in the construction industry were not likely to be able to (or want to) invest in computerized information systems;
- The processes around contracting and paying for construction services:
- Are inherently collaborative;
- Are repetitive both within the context of a project and across projects;
- Involve the same players are working together again and again.
- Many of these processes were monstrously inefficient;
- Most of the industry players took the inefficiencies we observed as givens;
- There appeared to be room for a high margin (given the volume of potential work and the rents we were pretty sure we could charge) player in this market.
Had we taken our conversations with our potential (and what turned out to be future) customer-base at face value (see bullet point four above), we would have made incremental improvements in the processes. But, we went further and observed what they really needed which resulted in the radical changes that we eventually implemented.
Remember, I said in my last post that you need to develop what the customer needs, not what they say they want. We didn’t take the business processes that we saw as being givens. We believed that through significant business process reengineering supported by technology that we could make significant improvements in the efficiency and effectiveness of the settlement and payment processes in the construction industry.
The strategy largely involved:
- Making sure that we had a good handle on the fundamentals of the processes related to settlement and payment and automating them. The ensured that there was a value proposition that was solid and that could be (in the language of our customers) be communicated effectively;
- Using a cloud platform (remember this is in 2002) to deliver services to a customer-base that didn’t want to invest in technology. This allowed customers to (with relatively little risk and investment) to try out solution;
- Getting to scale as quickly as possible. We understood the power of the network effect (given the collaborative nature of the settlement and payment process) and that it would be important to ensure that enough of the construction community was on our platform to make it difficult for competitors to get a toe-hold;
- Providing a level of service (i.e. spectacular product support) that was unknown in the enterprise software arena. This facet of the strategy had many components, but we felt that treating customers well is key to the long term success of both the product (its extensions and complements) and the company.
There were lots of things we didn’t get right:
- We underestimated the resistance to automation of basic and key business processes;
- We initially got the charging mechanism wrong;
- We initially got the pricing model wrong;
These “mistakes” slowed us down. But, mistakes were inevitable. The key is understanding that a strategy is not immutable. And, when you get things wrong, you must have the courage to acknowledge the error and move quickly to correct it. And, in most cases we did!
It is not possible to convey the level of detail that Pat and I worked out in those first few months in the context of a blog post, but let me close by saying that my notes from that time period provided enough detail to be the basis for patents which we secured as part of the process of getting Textura launched and that provided Textura with the cover that it needed to get off the ground!
I will note that the detail found in those patents was several levels of detail more specific than the Product Strategy that Pat successfully used to secure funding, not an easy thing to do. And, not just one round of funding, but all that were necessary to fund the development of the core payment and settlement product and more.
So, in this case, Product Strategy was used to help secure financing for the startup, provide direction to the product development teams and to direct the sales teams on their initial discussions with Textura’s first clients. While that doesn’t quite cover all of the territory that I laid out for a Product Strategy (in my last posting), it is certainly enough to make my point about the importance of a well-defined product strategy.