Business Tech: Case Study

Lineage

My Grandpa Charlie — I'm named after him — used to move to a new town, start a business, and sell it off once it was profitable. He did the hard work of making it happen but didn't like to stay involved. Between businesses I've worked with, ones I've worked for, and ones I've owned, I have started several businesses myself. I'm just not as keen about walking away.

Presently, I'm involved in starting up five businesses. In two cases, I'm doing some mentoring. In one case, my wife and I are building something new. One more I can't talk about, yet. And, the last case, LAFP, is one where I am a partner. I'd like to use LAFP as a way to talk about business and technology a little differently.

Birth Pangs

LAPF is short for Love At First Page. It is intended to be a dating site for books . The idea is that you can fill out a questionnaire, like you would on a dating site, but instead of some potential lifemate, we would match you to some enjoyable reading.

David Arney put this idea out to see if he could attract any attention. Joseph Persia egged me into getting involved before he split off to try a different approach to the same business. Another possible partner, Steve Burham, stepped back because of work commitments to his day job. That left three of us, David, Karen Conlin, and myself.

There could be a whole article derived from that last paragraph. We did the fast-forward version of what many multi-partner start-ups do. We fractured. To be clear: if you are in this situation, keeping everything on good terms is good sense. If Joseph's split-off results in a service which also gets to market, then the cost of educating the public that this category of service exists just got cut in half. Having competitors makes this a market segment.

As to Steve, he may find himself drawn back into the idea — on our team, on Joseph's, or on his own — and that means that goodbyes can be temporary.

Tech as a Business

Since this is going to be a web-based service with a strong algorithmic aspect, you might mistake this for a tech business. It shouldn't be. It should be a math business. The statistics, modeling, and updating of the questions are the key to success. So long as the user experience (tech and design) are acceptable, the math will make the difference.

This is a Business Tech column, so I will be focusing on the technical parts. That does not mean they are the most important.

As with every other business, we tech folk do better if we understand the model on which the company is basing itself. As we see it, we have four audiences: (A) Readers who don't want to use the match-making but would like to browse any site which has books, (B) Readers who want a match, (C) small press publishers and self-published authors who want their books to be found more easily, (D) people who want to advertise to the previous three.

That fourth group is problematic. On the one hand, ads mean funds. On the other hand, good ads distract people from our site. On the third hand — yes, yes, I know I said we'd be good at math — bad ads can chase people away from the site. We will be holding off on talking about ads for now.

The third group is the real focus. All of our math and matching assumes that we have a large enough database of books. To satisfy the first reader, we have to have enough variation in our selection to find his or her perfect book.

Actually, perfect is the enemy of the good. Even if we had every book indexed to our algorithm, we are much better off recommending good books over perfect books. This is why Love At First Page is a working name and not the final name we intend to use. Love is too big a promise.

Since this is question-driven, we need to look closely at the mechanics of how we will ask questions. While I could write this all in some flavor of our beloved Basic, I will be building this part in PHP. Even though the specific questions we ask publishers and authors will change over time, the mechanism is likely to be consistent; we need to allow responses to create branches. Anyone who has written telemarketing software will recognize this approach.

The challenge is to make the data (questions, in this case) manage the branching so that the software does not need to be re-written as the algorithm matures. I'm looking at a data architecture where the data will include two "tree" identities: (1) this question lives as part of branches 6, 7, and 9, and (2) this question — on a yes — switches us to branch 18 or — on a no — leaves us on the current branch. In code this would be something like this:

005 6]7]9
006 Y]N
007 18]0

We will have to account for answers beyond yes-or-no, and allow for some or all answers to be significant in their ability to change-up the questions which follow.

The questions themselves are unlikely to be 100% static. For example, we might want a question to build on previous information, which is why we intend to incorporate word merging.

001 When you said that {{book_name}} is {{genre}}, is that exclusive or are is it also any of these:
...
006 {{assoc_genre_1}}]{{assoc_genre_2}}]{{assoc_genre_3}}

As you can see, if the question has to be merge-able, we have to allow for the answers to have the same flexibility.

I like PHP for this because I can store variables in the session and re-use them for merge. Yes, it could be done in other ways, but this is very clean.

Obviously, the same database structures fit the need when we question the readers. Knowing that we are building two paths makes us think more carefully about how we implement this code.

I'm still picking through the details to see what other challenges I need to factor into the database architecture and the code.

Wrapping Up

Remember, this is a start-up. There is no guarantee that the project will ever be completed. I'll update you if anything else Business Tech-worthy comes up from this or any of the other businesses in my incubator.

Featured:

May/Jun 2013