Now that we’ve built the foundation, it’s time to start churning out product ideas. My goals are to complete enough of each idea to present either directly at our internal technology day, or to use as an example for a point I’m trying to make during one of my presentations. The by-product of the efforts is to gauge interest with the users, test the concept in “the field” for ability to execute, and overall practicality. The decision point will be whether each of the ideas is worthy for further consideration and additional buildout. That’s the MVP punchline.

I’ve judged these ideas to be in one of three states: Viable, Not Viable, or Inconclusive.

• Viable: Shows promise as a potential product offering. Feedback from the current iteration needs to be incorporated into its design and/or implementation and it will be re-evaluated after the next round of viability testing.
• Not Viable: Based on user feedback, changing business landscape, field testing, time-to-market or a host of other things – no further work will be performed on this idea. Certain subsets of capabilities may be utilized on other ideas, but the overall concept is not going to fly. This doesn’t necessarily mean it will never fly, but at least not right now.
• Inconclusive: Results were unclear either way. Maybe a modification of one or more of the variables will yield measurably better or worse results. There are a lot of things in flight at the same time so it’s hard to determine which lever to move in order to get a change. You have to determine which ones to move and how quickly in order to systematically determine a true outcome. In the face of ideas that are “Viable” it may not be worth chasing these geese.

Based on these criteria, the 3.5 ideas exercised during this two week stint fell out like this:

Product Idea #0 – The Foundation – VIABLE
To me, this was a no-brainer, but we had to build the foundation in order to show it definitively. We spent maybe 40h putting together the infrastructure pieces (in this case: Linux, Subversion, Ruby, Sinatra, Thin, Phusion Passenger, and CouchDB) with all the associated glue that goes along with it. We tested it and made sure that it was stable enough to start building upon with the goal being a demo after two weeks of calendar time. Once we finished it then built our three ideas on top of it, we were ecstatic knowing how quickly we could now turn out tangible results. The foundation would be invaluable going forward.

Utilizing RESTful web services and a document-oriented, NoSQL Database, we could build an architecture that once operational, would allow us to build products that utilize that architecture quickly, even if the ideas had a fundamental difference to them (especially in the data structures), thus allowing ideas to be cycled through and proven/disproven with very little effort or oversight.

While not really a product (for external consumption anyway), I’m going to treat this as an internal product much like 37signals treats their internal system named “Queen Bee”. This is the piece that will serve as the launching pad for all future endeavors so it needs to be productized so as not to limit what we can do later. It won’t ever be the sexiest product we have, but arguably the most important.

Product Idea #1 – The Consumption Engine – VIABLE
The idea was to build something that would consume transactions in such a way that it would scale quickly; be autonomous by being able to start from scratch, clean up after itself and not care if 100 other instances were processing along side of it or if it worked alone; and be flexible in being able to perform several types of work.

The EC2 AMIs were designed to be like “Frosty the Snowman”. You throw the magic hat on his head, he wakes up and says “Haa-peee Buurthdaaay!” and starts dancing down the street. In our case, we would spin one up, it would grab the latest code from our remote svn repository, and start processing transactions from the queue.

Because we externalized the specific application logic, the tasks that the Consumption Engine performed could be completely controlled by the code it checked out. So today my engine processes registrations, tomorrow, that same engine processes orders, the next day it processes shipments. If at the end of the month, I needed to burn through a completely different set of data, I just need to put it in the repository and the Consumption Engine picks it up and starts running.

What Did We Prove: Scaling up and sharing work is not too difficult to do, and to do it in a manner that is flexible enough to operate for multiple applications takes just a little bit of extra thought. It also proved to me that you have to embed the target architecture in to the design phase of your application. You just build something then figure out how to scale it later. You need to go in with that mindset. The work needs to be organized specifically for grid-type processing, and any applications built for scalability will need to understand how to do that.

Next Steps: While this is a viable product from an internal perspective, and one that we’ll use if we ever hit it big, for now it will become a “best practice” document and serve as a “cloud architecture pattern” for future projects.

Product Idea #2 – The iPad Control Panel – VIABLE
This idea came up 2 days before the demo and Tom was able to leverage The Foundation and The Consumption Engine in order to put together a functioning control panel to start and stop AMIs and toss transactions into the queue on demand. It wasn’t pretty (looking), but it did the job with no rework of the underlying architecture.

People talk about the “C”s of Creation and Consumption and how the iPad is a “Consumption” device. They neglect the other “C” of Control. That is a powerful avenue that we’ll be exploring further down the road.

Product Idea #3 – Participant Bar Code Scanning – INCONCLUSIVE (sorta)
The registration of event attendees and the measuring of their interactions worked as we thought it would. But there were a few base level requirements that could not be met practically. First, everyone needed a smartphone. Ironically, this technical conference included a large number of technical attendees that did not own a smartphone. OK. We have a technology staff that lags in technology. Eventually it will be rectified because in a year or two there will only be smartphones. A second “gotcha” was since I was using a 2D barcode that carried a simple RESTful API call as opposed to a fully baked custom app, I could only measure when a certain name badge was scanned, not who was scanning it. Thus I could only see one half of any particular social interaction.

Nevertheless, it was being used and talked about. I could beef it up and turn it into something marketable but there are better ideas on the table. We only have a few large meetings a year and those are more weighted towards project managers and process wonks so the smartphone requirement may be further from being met.

Other outcomes from this exercise:

1. Additional ideas!
2. Technical documentation including architecture and configuration specifications.
3. Many blog posts. These three MVP-related ones, and many more to come on the specific technologies used.
4. A $100k contract that arose from having knowledge not possessed at the beginning of the 2 week effort, but gained during the course of the experiment.

In the end, A Pretty Good return on our investment!

An app for the iPhone performs its designed function, similar to an app written for any other platform. It’s written in Objective-C, runs when you tap its icon, and generally behaves the way that app does in any other environment. The phrase historically for this type of app is “a port”. It existed somewhere else, now it’s on the iPhone. Woohoo.

Contrast that definition with that of a true iPhone App. The iPhone App takes advantage of its capabilities. It’s rethought from the ground up. It performs the same function of it other-platform counterpart, but either does it in such a way that it becomes a new user experience, or adds additional functionality that’s just not possible in its legacy heritage.

I’m not talking about just leveraging the base SDK functionality to build your application, I’m talking about reinventing it. Your device knows where you are, how can that information help make my user experience better? I don’t have a real keyboard, what can you do to mitigate that issue? There are so many capabilities to the platform that any effort to build an iPhone App should include brainstorming to figure the best ways to utilize those capabilities.

This same line of thinking goes for iPhone to iPad ports too. New device. New rules.

In my experience, the IT shop sampled here is pretty typical. A lot of legacy systems to support keep them firmly entrenched in the Classic section. They’re moving towards the next technology level, but a combination of inertia, lack of a sufficient force (e.g. customer demand) and the fact that everyone is swimming against the “technology current” (Imminent becomes Current, Current becomes Classic), keeps them perpetually at their current level. They may have dipped their toes in the water with some current stuff, and a few rogue employees have been doing some things in the Imminent column with unclaimed machines that would probably get them yelled at for “wasting time” as the CIO/CTO hasn’t envisioned it yet. Usually this is OK — at least until a competitor leap-frogs you.

Leap-frogging over technology eras can happen in one of two ways:
(a) The easiest way being to be a startup or a small company with no real legacy history/baggage. In this situation, you can simply choose which of the current or imminent (or hybrid) technologies best suit your business needs then implement it. You’ll immediately be in front of whatever competitors you may have and hopefully your business model is as forward thinking as your technology model and you can turn your industry on its ear.
(b) The harder way is to transform your shop. If you’ve got an entrenched set of tools, way of thinking, and overall outlook on life, then it usually takes an external influence…kind of like something out of the (a) bullet point above to force you into action. In this situation, trying to play catch-up is probably not the right approach. By the time you get there, you’ll find that Current has become Classic and you still in the same situation. Here is where you pick some of the more reasonable Imminent items as well as items from the Current stack that will help you bridge the gap and make the jump.
Of course you need something to jump to. If you’re doing this just so that you can keep doing business the same old way, why bother?

The classic definition of MVP involves getting almost real-time market feedback on your ideas and letting that determine what your next step is. The increments are small, so your risk is likewise small. And since it’s real market feedback – from the whole market (not an artificially contrived subset), there’s a lot less interpretation needed as to the market’s wants and desires (or lack thereof). Obviously there are complexities that still remain. For instance:

• Is my idea failing because my AdWords ad is poor OR
• Should I spend more money to buy the really “good” keyword phrases OR
• Does the landing page not get the idea across OR
• The graphics aren’t cool enough OR
• There’s too much competition OR
• There’s not enough competition OR
• Maybe it’s just a bad idea.

There are still a lot of decisions to make. As I mentioned in the previous post, we threw 1/2 dozen ideas into the market ether for 2 weeks. One came back with very good results, four with better than expected results, and one that surprisingly didn’t do as well as expected. A couple of them were iPad applications that were tracking along a mediocre path until the first TV ads for the iPad started to come out, then they shot up quickly. Interesting.

We could have continued to refine the concepts to get even more insight, and had we wanted to continue to spend money, I’m sure it would have been worthwhile. But there was one insight that was immediately actionable that caused us to temporarily stop watching and start building. All of the product ideas we threw out there were based on a common architecture. If we built that common architecture, then we could plug and play product ideas as quickly as we could come up with them. The common architecture would be the basis for future MVP testing. Instead of simple landing pages, AdWords would come straight to products that ranged from minimally viable to fully viable depending upon where they were on their evolutionary scale. It would be cool to prove this though. In a minimally viable way.

The internal company technology day was 2 weeks away, and I needed to show off Amazon AWS – but, I also wanted to push the foundational product idea forward a bit too. I came up with a problem to solve that would let me demonstrate EC2 and SQS and resolve the classic elasticity problem by spooling up machines to handle a spike in demand, then throwing them away when the demand spike subsided. Essentially, I had a queue that was accepting incoming requests, and in order to process them in a timely manner 1-n machines would be spooled up and immediately begin consuming records from the queue. It’s a simple problem, but actually mirrors how we design our mobility apps for gathering usage metrics and will have implications if we ever “hit it big”. Nothing wasted. Everything is a proof-of-concept for something else.

Here are the basic steps I followed in order build the architecture (eventually, each of these will become their own blog post eventually, but I need to try and stay on the MVP track here):

1. Build an AMI (virtual machine) [not MVP]
2. Install Required Components to Run Solution [not MVP]
3. Write & Test the Solution [not MVP]
4. Build MVP Products on Top of Solution [MVP!]
5. Profit

Steps 1-3 are not really the MVP portion of this, but they’re the steps that enable MVP to work. For Step 1, I picked a CentOS distro of Linux since that’s the distro used by my hosting company (keeping them alike lets me leverage efforts in both directions). For Step 2, I added my operating platform of choice. This platform is completely appropriate for how I want my environment to work in my MVP future, but completely irrelevant to solving the conjured problem at hand of solving spiky demand. Since it’s AWS, I could have used just about anything.

Why these technology components?

1. Base Development Language: Ruby

• I’ve got enough grasp on it to be productive using it.
• It’s great for quickly prototyping, but if the product gains popularity, I can scale it up as well.
• It’s got a gem for just about everything I’m going to need to talk to.

2. Ruby Framework: Sinatra

• Dead simple creation of RESTful Web Services.
• Reading and writing JSON was also dead simple.
• It’s small, quick, and stays out of the way.
• Everything we plan on building is going to have a RESTful hook into it so that it’s extensible by us or external developers.

3. Other DSLs: haml & sass

• Writing HTML is a pain.
• Writing CSS is a bigger pain.

4. Deployment Architecture: Phusion Passenger on Apache

• Simple to install and configure.

5. Database: CouchDB

• It speaks native JSON.
• It’s schemaless (NoSQL) and I’ve written enough SQL in my life. Additionally, a lot of what we plan on building will need flexibility in how information is presented and stored. Schemaless makes it trivial to do some of the things we want to do. We’ll still have a relational component to our products and internal infrastructure, but we already know how to build those.
• With RESTful architecture it’s easy to get data in and out.
• Replication between temporary sites and the permanent data store was one ‘curl’ statement.

OK. So there’s my stack. Is this setup going to solve my manufactured problem and provide a launching pad for us to build products quickly going forward? Actually, yes. It will.

As you can see, getting ready to handle MVP takes some work. The last item in this series will discuss that actual products being built on top of this architecture. In all, there were three. The solution to the actual problem, and two more that we came up with when we saw some of the possibilities that having this type of a foundation presented.

Upcoming Topics will include:

1. The validity of a Minimum Viable Product approach to product development
2. Some Web Squared and Internet of Things stuff
3. CouchDB (I’m in love with it)
4. Sinatra (Don’t tell CouchDB but I’m in love with this too!)
5. Results of a 2 week, 3 prototype jam session (you can get a lot done, including documentation and demos when not encumbered by needless process and you use the right tools)
6. Mobility and why it’s bad to isolate in you overall architecture (ditto for cloud, social, sensor, and data concerns)
7. More Agile stuff
8. iPad/iPhone development with REST, cloud, etc.
9. Amazon EC2
10. bunches of other stuff!

So, as you can see, I’ve been busy for 6 months.  Hopefully, some of this will be entertaining, interesting, or at the very least, informative.

The world of consulting is not immune from this rapid change, if anything, depending upon the type of consulting that you do, you may actually be in a worse position. Not recognizing that you passed the “peak oil” of whatever your specialty happens to be, going from project to project looking for better ways to extract crude from the shale, without realizing that there is an abundance of productive new fields opening up all over – has you looking at the wrong side of the profit margin slope and stuck on projects that don’t position you for the next “big thing”.

I’ve been a consultant for 15 years now after spending about 6 years in industry. I’ve worked for boutique firms, “Tier 1″ firms (Andersen represent!), and “firms” in the middle. One of the things most of them have in common is their general operating model. You know, how they make money, how they sell, and their general outlook on the marketspace. These are some of things that are going to need to change over the next several years in order to move ahead.

As part of this series, the main idea I want to explore is reversing the order of precedence in a consulting company (or any organization, company, department, etc.) where a marketable talent should be the basic unit-of-measure by which that organization is judged. Where the success of whatever organization that talent is attached to is dependent upon nurturing, marketing, and harvesting that talent. Make the talent be the entry point to new projects, not the sales staff. To this end, we’ll be:

1. Building a model that operates more like a sports team rather than like a 1950s, top-down, “Tin Men”, sell-or-die mentality;
2. Avoiding a fall into a “Jennifer Government” type relationship with your employer. Consultants are responsible for their own marketability, thus their voice needs to be their voice. If done right, the voice of the consultant can be of simultaneous benefit to the “firm” too.
3. Focusing the message, generalizing less – but at the same time not becoming hyperfocused.

The selling model will be first. What we will need to breakdown is the notion that because sales is a low-supply, high-demand scarce resource, it is more valuable than the plentiful resources used on the delivery side of the house. While I’m not one to try and turn basic tenets of simple economics on its head, I am one to flip the problem around a bit so that I can show that maybe the types of people we generally think we need to fill the sales and delivery roles, are not the ones we actually do need.

My goal is not necessarily to marginalize the sales effort or the people that perform it, as I don’t think they should be an order taker any more than I want to be considered an order filler. Rather my goal is actually to make people that focus on doing delivery well, worth a dozen dimes instead of being a dime a dozen. 

I’m working on a series of posts that deal with making us (myself included) better consultants, changing the old sell & deliver model that rewards the wrong side of the equation and nets our clients a “net-static” solution at best.  The theme will be to quit proposing a “business as usual” stance.  All too often, we as consultants tell companies, “You’re not in the ‘so-and-so’ so you need to focus on your core strengths.”  Maybe that’s not the right answer anymore.

Things are changing.  Rapidly.  The old solutions are just that…old.  It’s time we start embracing the change and tell our clients, “Sorry, you used to be an insurance/medical/financial company, but now you are a technology company – and you’re doing it wrong.”

What is the backchannel? Murmur, background noise…you know, those annoying side conversations during a meeting that usually only serve to disrupt and distract from whatever the main person in the room happens to be talking about. That’s the backchannel. Sometimes they’re secret discussions about you (at least in your mind they’re about you) that take place in closed-door offices. Or sometimes they’re all the chatiness happening over instant messenger while you’re sitting on a boring conference call. Or it can be even something as simple as the comments on this blog posting. Some people refer to it as a meta-conversation (conversation about the conversation) or even sidebar discussions, but regardless of you choice of phrase, the backchannel represents all conversations that are not part of the main thread of discussion – however are somehow contextually related to you either by subject-matter (topical), geography (locational ), and/or intimate frame-of-reference (personal).

Topical
The topical backchannel context involves groups of people that are congregating for a specific purpose. These could be meetings, rallys , conferences, concerts, sporting events, etc. – but essentially everyone is there for a common purpose. The participants may or may not be all physically in the same location (for web conferences, people are scattered all over the world) but it’s the subject matter that draws them together. It’s a shared purpose.

Locational
Where topical backchannel conversations have people sharing their experience around a subject matter, the locational backchannel has experiences being shared around a common geography. The geography can be hyper-local such as a stadium or arena, or more widespread like a neighborhood or town. The topics being shared can be varied, but the context maintains relevance by tying everything together via the proximity to the other participants. A perfect example of this is using your Twitter client to see all the tweets being broadcast in your immediate area. The subjects of those tweets can range from announcing dinner plans to lamenting about work but interest is piqued by the fact that these are neighbors of your in some way.

Personal
Personal conversations may or may not have topical or locational contexts that relate to your own situation at that particular moment, but you care about what some people say because you have some vested interest in the actual person. They could be friends, family members, co-workers, or someone of a varying degree of celebrity. While, it may not always be interesting conversations they’re having, but it is always pertinent to you. This is why you follow certain people in the first place isn’t it?

Purpose
The primary purpose of the backchannel is to give someone an opportunity to be heard. Whether it’s about expressing an alternate opinion, obtaining/providing clarification on a comment, or airing some form of agreement/disagreement – it’s an empowering form of expression. There may be 1000s of people involved with whatever is going on, but each backchannel voice is equal in weight. Assuming you’re even listening that is.

The secondary purpose is for sharing experiences. “I am here”. “We are here”. People at the front of the group, relaying messages to the people in the back. “I just saw so-and-so, I think the band’s coming out”! “Accident on I-71, take the lateral to I-75 instead”. These relationships can be formed and broken in a matter of minutes or hours, but the value of the interaction can last for much longer if you listen correctly.

To the actual participants of these out-of-band conversations, they get value from the interaction itself. But if you, the provider, are savvy enough, you can give them extra value by reacting timely to their discussions.

Value
The forechannel discussion, without the backchannel is a flat subject. Two dimensional in that it has height and width, but no real depth. A backchannel discussion without it’s forechannel has no context, It’s essentially just random noise. Together though, these two channels can form a symbiotic mesh of discussion where the forechannel gives relevance and shape to the background noise, and the backchannel gives the main idea more depth and understanding. OK, that’s maybe a little obtuse. How about a couple of examples:

1. Giving a presentation for a local user group, the speaker has been through this material dozens of times. In order to keep it fresh for himself, the speaker gives the audience a Twitter #hashtag to use while he’s wading through the material.  He tells them that while he welcomes any questions during the talk, if they ask them via Twitter, he can address them during the appropriate portion of the presentation. A positive of this approach is that all of the gathered questions can be compiled and used to refine the message, establish FAQs, get direct contact information of the participants, and possibly sift through the conversations to find new avenues of business.
2. A downtown venue is hosting a sold out concert event and a few hours before it begins, starts to monitor the backchannel of patrons registered for the event talking about excitement for the event, traffic issues, and what they hope the band will be playing that night. Based on the number of messages about leaving for the event, the venue can estimate when the bulk of the crowd will be arriving. Complaints about traffic can prompt response back out to the incoming fans about alternate routes and which venue gates have the shortest lines. And the performing band can use the desires of the audience to maybe add a song to that night’s set that originally wasn’t scheduled to be played.
3. Getting ready to go out on the town, every couple, family, and group of friends has the same discussion - “Where do you want to go/eat? What do you want to do/see?“. Each person surfing their personal backchannels can quickly come up with new restaraunts or movies that quickly get narrowed down into a decision. Sure, there are web sites and iPhone apps that will let you see reviews of local places, but the power of the backchannel is that it makes recommendations more personal. In the end, all decisions are made with a mixture of logic and emotion and the personal backchannel provides that emotional element when logic cannot choose between two or more equal unknown options.

Obviously, a lot of things need to happen in order to make this work, but the building blocks are all there to do it today. Web Squared, the follow-on to Web 2.0 according to Tim O’Reilly, will help make these mainstream capabilities. Acquiring the data will not be the barrier in making use of the backchannel, rather it will be the sifting and application to their specific needs that will require the imagination and effort. This is why high-end data skills will be one of the hottest markets and job opportunities during the next wave.

It’s Not About Control
You can’t control the backchannel. Don’t even try. The more you try to shape the message, the more you’re not going to like how it comes out. Your job is to enable the conversations, capture them, and adapt yourself based on them. You can take the inputs and transform them into something useful for yourself and others, but in the end, it’s not your message because you didn’t create it, you just allowed it to happen.

Summary
If not officially provided by the venue, sponsor, or host, these backchannel discussions will occur organically. People will make up hashtags or keywords that make the most sense, or follow the lead of their neighbor . Some of these conversation snippets you may be able to find later by randomly looking for tell tale keywords that your audience may have used, but a good portion will be lost into the ether – at least to you. These could have been the most damning comments or those harboring the most praise. In either case, you won’t be able to use them to your advantage if you can’t find them.