Category Archives: Technical

These posts are technical in nature. The casual reader may not care about these posts. These are for my fellow geeks.

Building a Better Web Application: Part 2

Note:  This is part 2 of a series of posts on building better web applications. If you haven’t done so already, please read part 1:

Where we Left Off:

In part one of this blog post series, I explained how to frame the basic questions around your web application:

  • What problem are you solving?
  • What purpose does your application play in solving the problem?
  • What audience will you be a hero to?
  • What functionality will your application have?
    By this point, I’ve compiled all of my current findings into a document and will call it the “Draft Project Definition.” You can use whatever system you like: A hand-written notebook, napkin, or something more sophisticated like Microsoft OneNote. I love to use Evernote because I can easily access my notes from the majority of devices that have Evernote applications available, or directly through the web interface. Once again, just use whatever you care to.

Using Evernote to document your progress

The point is that you now have something to show someone should they ever ask you what you’re working on. It’s a pretty quick projection of your plans and should only take you an hour or two to put together. You could spend more if you are building this with someone else and/or are iterating with a client.

Can We Code Yet?

This document is something that we developers are usually opposed to. Documenting our process is about as painful as anything we can imagine. We just want to hurry up and get to the coding part. I know it is unintuitive for some of you, but the coding part should be much more enjoyable once you’ve got all this behind you. It means you’ll have fewer interruptions explaining what you’re working on once you do start coding.

Ready for The Next Step?

The feedback I received on the first post was overwhelmingly positive. I’ve got several contacts from individuals saying they are ready to walk through this process. My question to them has been “What will you do once you’ve defined your problem, purpose, audience and functionality?” Most of these individuals have said they will continue to define the finer feature set. One person said they’d just wait for my next blog post. For that person, and the others who have asked me to post part 2 quickly, I’ve decided to expedite this post. I’ll pick up where I left off and introduce “Step Five – fine-tuning your functionality through innovation and emulation.”

Step 5: Innovation and Emulation

In the previous post we defined the following five broad strokes of functionality:

  • Low-Barrier Community Contribution
  • Rewarding Community Interaction
  • Compulsive Browsability
  • Personalization
  • Diverse Delivery
    We need to get some clarity on our functionality, but we still aren’t ready to define implementation yet. We are going to do two things, however, that will make all the difference in the world: brainstorm on proposed functionality (innovate), investigate your competition or other applications that have (emulate).

I opt to do the brainstorming (innovation) part first. After all, if you are just going to copy someone’s work, you aren’t solving a problem! If you are copying someone else’s work, you aren’t building something that fits your defined problem and defined purpose. If your problem and proposed solution match up enough to someone’s site you haven’t been paying attention and you’re doing it wrong! If you’re doing it wrong, please go back to phase one and start again. This time, remember that step two is about solving a problem in a unique way!

You should opt to do your brainstorming first so that you aren’t “encumbered” into coming up with the same sandboxed solutions that others have invented. Many a website is simply a shuffling of the deck chairs and they don’t last long. These “carbon copy” sites don’t distinguish themselves from their competition.

I’ll use the example of Facebook and MySpace again. Remember that MySpace and Facebook had similar functionality. Someone might try to argue that Facebook copied MySpace’s problem and purpose. That’s not true. Arguably, MySpace was solving a problem of allowing hosted, heavily-customizable home pages. Facebook was solving the problem of building an easy-to-contribute, easy-to-extend platform that connected you with your friends and topics of interest. They had a similar problem, but had VERY different approaches to solving the problem. Don’t copy, shift your thinking on the solution to the problem and go from there.

That said, both innovation and emulation play distinct and important roles in developing your idea.

Solution Brainstorming (Innovate)

For each of your functional areas, think of everything from the most rube goldbergian implementations of your functionality that your imagination can muster to the most simplistic. Write it all down or whiteboard it out with others to get an optimal effect. Having good people to bounce ideas off of is key. I will argue that you should not make your brainstorming group too large. One or two people is actually plenty to get the intellectual banter working (see my previous post on Actualization and Collaboration).

Don’t constrain yourself in this step, to the most practical and probable ideas. Even if an idea comes to mind and seems completely useless, impractical, unwise or otherwise undoable, write it down anyway. You aren’t going to include all of your ideas in the final solution. You’re just capturing the ideas for now. Write down some practical solutions too. Write down as many ideas as you can and as quickly as you can do it. Just let the information flow straight to your pen. Don’t think about what everyone else has done or will do. Just free-flow information no matter how ridiculous it may seem. The point with writing down the improbable or impractical solutions is to get you thinking outside of the solutions that everyone else has thought of. If you constrain your thoughts to what you know you can do, you’ll come up with some of the same tired solutions.

In my example of a content curation system, I’m going to write the following:

Low-barrier community contribution

  • Hand-written notes added to system
  • Devices given to people which will automatically contribute content
  • Toolbars / Browser plugins that allow for submission and voting
  • WordPress plugins that allow automatic contribution
  • Forum plugins that allow submission and voting
  • Stream content from existing community sites
  • Anonymous posting w/ability to link to a real profile later
  • Poll for content from the community

Rewarding community interaction

  • Gifts delivered to the home of users for extreme participation
  • Sponsored software or services for participation in product-related discussions
  • Points / Reputation system
  • Most active content reviewers rewarded with weekly column
  • Ad revenue sharing based on quality of content submitted
  • Get paid for milestones reached (combination of quality and quantity gates)

Compulsive Browsability

  • Additional content presented based on content you’ve viewed or contributed in the past
  • System predicts what to present to you based on linked profiles/interests
  • System predicts what to present to you based on the content that your friends you interact with most are looking at


  • Allow filtering based on tags
  • Allow filtering based on words found in text
  • Allow filtering based on what my friends have read
  • Allow filtering based on what my friends have recommended to read
  • Designate a delegate to curate my content for me
  • Follow company recommended reading
  • Follow product group recommended reading

Diverse delivery of content

  • Carrier pigeon delivery
  • Existing Standardized Aggregation
  • Hand delivered each morning (like a newspaper subscription)
  • Monthly personalized magazines – Physical and Digital
  • Deliver headlines, summaries and “key quotes” from articles of importance
  • Delivered to phone through notification – one article at a time
  • Summary of all curated content delivered to phone through notification
  • Filtered content delivered to phone, unfiltered delivered in summary (split importance)
    When you’ve completed this process, you’ll likely notice that you are weak on a few functional areas and have a LOT of ideas for others. This is OK for now, but if you finish your next step and are still light on ideas, you’ll want to start iterating specifically on the light areas until you have a large list of items to chose from.
    Once again, I write down my progress into a system so I can keep track of it. I won’t go into too many details of my personal process because it doesn’t matter how you do it so much as that you do it. I create a new note in Evernote under my project for each bit of functionality and list the findings of my brainstorming there. Once I’m done with the due-diligence part, I’ll add the findings from that process to each note. I’ll show you a screen shot of my system at the end as I don’t want to get too caught up in those details just yet.

Competitive Due Diligence (Emulate)

For each of your function areas, identify who might provide this functionality already. It doesn’t have to be someone who is working on the same area. It can just be a tiny piece of functionality from an unrelated site that you want to emulate. For instance, the website “Ravelry” is a well-known knit and crochet site. Surely I don’t want to solve the same problem as them. However, they have solved some problems along community interaction that would be fantastic to model after.

Don’t limit your learning to just the good site examples. Make sure to document the poorly executed solutions to your problem too – you don’t want to repeat other’s mistakes! For me, I take a screen shot of the functionality from various sites and then list pros and cons for that implementation. For instance, look at my first piece of functionality, “Low-barrier community contribution” and see how I broke out some functionality to emulate:

Low-barrier community contribution

Facebook Wall Posting



  • After signing up contributing is very easy
  • Link posting fills in the data after simply posting a URL
  • Photo submission can be done through attached devices or through file upload
  • Upload from any device


  • Requires sign-up before contribution
  • Privacy concerns raised through the years limit what some people will share

Facebook Like Button



  • One-click contribution makes for very limited contribution AND sharing across social networks


  • Privacy hard to get right

Stack Overflow Ask a Question



  • No log-in/sign-up required. Simply a name/email will suffice
  • Optional log-in allows use of OpenID – registration therefor is low-barrier
  • No need to select the right “forum” to post your question. Multiple tags allow for your question to catch the attention of anyone watching those tags


  • May feel intimidating to respond to questions
  • Community can be harsh at times – driving off would-be contributors

Posterous New Entry

(No Interface Required)


  • Post by emailing
  • No sign-up required – just email your first entry to
  • Easy submission to your personal <name> address allows easy update of your Posterous page.


  • “Feels” like a high-barrier to submission if I don’t want to open my email

For each functional area, I would continue to do this for as many sites as I felt necessary to start seeing patterns in the pros and cons. I’d probably list several others. Off the top of my head, I’d list Wikipedia, Reddit, Twitter and Hacker News (which has a similar “purpose” as my fictitious business, so it’s good this is a hypothetical business for me).

If you can’t immediately think of a pro or a con of a specific item, try vetting it with others. Do mini-usability studies by asking someone else that you know to use the product or service and give their feedback while they are using it. This should give you some off-the-cuff responses that will help you really dig down into what is good and bad with a site’s implementation.

Remember, you are scouring these sites for what is good and bad about that SPECIFIC FUNCTIONALITY  that you are currently investigating. You don’t want to get side-tracked into saying “Oh, they also have <x> functionality and I really think I should do that too!” This is where scope creep happens a lot. Many of us just want matching features because they feel that’s the only way to compete. If you look at solving your problem the way everyone else does, you’ll never be a competitive player. Additionally, all the work you did in steps one through four to keep your scope manageable so you can love your customers will be for not. Stay disciplined here and focus only on the functionality of a site that matches your functional areas. For instance, I LOVE that Posterous allows me to easily theme my site. However, that isn’t in scope for THIS functional area so I’m not going to list it as a “pro” under “Low-barrier community interaction”. The theming feature will, however, fit into my “personalization” functional area. So don’t include everything about the site that you like. Include only the pieces from the site that refer to the given functional area.

I’m going to state again that you aren’t just looking at existing applications who are solving your same problem. You’re looking at anything that has the functional area you are looking to provide. Posterous isn’t solving the same problem that my “curation” problem is. Facebook isn’t anywhere near my same problem area. However, both of those sites offer insight in the functionality that people have come to expect. If I start copying their features exactly, I’m going to be solving their problem, not mine. My application will fail miserably!

Step 6: Putting the Chocolate in The Peanut Butter (Integrate)

During the 80’s, Hershey’s produced a commercial for Reece’s Peanut Butter Cups. In the commercial, a man is eating a chocolate bar and a woman is, for reasons we may never know, eating peanut butter directly from the jar. They are minding their own business, walking their own separate paths when they come to a cross-roads, bump into each other and exclaim “Hey, you dipped your chocolate in my peanut butter. Hey you got peanut butter on my chocolate.” For some reason the two strangers feel they both have good enough hygiene to eat after one another. The result is that they both liked their new peanut-butter/chocolate concoction.

We haven’t talked you into producing a mission statement, THANK GOD! We haven’t produced a functional specification for our software. We have, however defined our problem and approach to a solution for a specific audience. We’ve defined feature areas and now we have brainstormed some of our own ideas and have looked at the way that others have solved the same problem. It’s time to put the two sides together to form the best possible solution you can.

As mentioned before, for each functional area, I have a “function sheet” in Evernote under my project folder. Here’s a screen shot:


You can use whatever software, or organizational technique you wish (hand-written notes, folders and envelopes for all I care). This works for me. Find what works for you. Admittedly, this is where I miss some of the organizational capabilities of OneNote so you may want to consider using that.

Notice that I keep my brainstorming and competitive analysis of a functional area in one sheet. Now it’s time to go through each one and hold another brainstorming meeting. Yes, I know. You just want to code. You don’t want to sit in these meetings about these functional areas. I agree that mindless meetings are useless. However, if you keep your meetings small (you and two or three other people – maximum), and the scope of the meeting limited to one piece of functionality, you can usually knock out some clarification work in an hour.

Look through the brainstorming section and try to imagine what unique and exciting way you can solve this part of the problem. In this phase, you are taking the ideas you have captured and are trying to create a workflow or multiple workflows for the feature. Don’t be afraid to incorporate some of your crazy ideas if it can make sense.

Here’s what I came up with in my own 2-minute brainstorming session on “Low-barrier community contribution”:

“Low-barrier Community Contribution” Workflow 1:

  1. User posts a link to twitter using a cell phone and uses hash tag #CR8ME (curate me).
  2. User receives a response tweet instructing them to connect their twitter account to the app
  3. User clicks on link, authorizes app, and new post is added to curation queue

In this workflow, I have slightly modified the crazy idea of handing out devices to people that will automatically contribute content to using a device the user already has.

Rabbit Trail: This was a lesson learned many years ago when I did some work for a company called ZapCode GoCode in the late 90’s. We were a competitor to the Cue:Cat. RadioShack gave away Cue:Cat reader devices (at a cost to them) which allowed you to scan a “Cue:Code” out of a magazine or other surface. This barcode would effectively link you directly to a site with more information. At the time, cell phones weren’t taking pictures. The scanner had to be connected to a computer. So you literally couldn’t use this anywhere but home where typing a URL might very well have been easier. These days, we can just use our cell phones to scan DataMatrix codes or Microsoft Tags and avoid the proprietary device all together.

I’ve also incorporated Posterous’ idea of “no sign-up required”. You could keep on going here and think up several more workflows in your hour-long meeting. The point here isn’t to solve the entire problem. You are simply thinking of how you can provide the functionality that is required in your overall approach to the problem.

Add your findings to the bottom of your “function sheet”.

Step 7: Experience-Driven Development (authenticate)

Now that you have an idea of what the workflow looks like for your function, you’re going to want to define the end-to-end experience of your functionality. This is your chance to be a bit more specific about the User eXperience!

But wait, shouldn’t we be defining the protocols and functions here? Shouldn’t we be writing code? Nope. This is something I like to call “Experience-Driven Development” (E.D.D. — not to be confused with E.D., because that’s a whole different problem altogether). Once you have an idea of the problem you want to solve and the basic functionality you want the user to have, you want to design the experience first and then let the technology support the decisions you make here.

You DO NOT want to pick a technology and then be constrained about the experience you can provide to your customer because of it.

Note: There are rare times that you will design your experience only to find out that no technology can solve your problem. These are usually due to decisions external to your control. For instance, I can design an experience that automatically authorizes your twitter account to connect to my application if I use the #CR8ME hash tag. However, twitter requires that I use OAuth and allow customers to manually allow that connection. In this hypothetical case my designed experience will not match the reality of the final solution.

Let’s design the experience. First, create a diagram of the workflow so you have a visual of the process and include some detail in the responsibilities.


You should also create some screenshots or create some mock-ups of UI that match your designed workflow. Use your due-diligence/competitive analysis to help you design UI that others are used to using. Remember that you aren’t trying to copy experience so much as reduce the barrier to entry by using familiar concepts for interface. Depending on your problem and intended solution, you may not have a UI at all. Everything you do may be driven by back-end services connected to someone elses UI (such as our twitter example). Notice that in this example, the user never had to actually interact with our web interface – only twitter’s OAuth screens?

You’re going to paste this into another new sheet in your notebook. I call mine “Experience Definition”  and use the format: “Experience: <function name>” as the subject. THis helps me connect my experience to the intended functionality.

Just for posterity sake, you’ll want to describe this experience step by step in as much detail as possible. You may want help developing the functionality and having the details will help anyone who picks up after you. To do this, I’m going to add a number next to each part of my diagram above.


Notice the numbers 1 through 11 on the individual boxes of the diagram? I’ll then create a document with an outline that matches these numbers. In each number section, I’ll describe, in full, what that part of the workflow is doing. Do this for each piece of functionality. You’ll likely have several diagrams and several documents for EACH piece of basic functionality we defined. It’s a little time-consuming but you’ll be happy you did it later.

In case you haven’t figured this out, the document and this diagram come together to form a pretty close facsimile of a functional specification – and we haven’t had to work very hard to get here.

What does all of this documentation gain you, as a developer?

Early Problem Detection:

Documenting the process here helps you better determine the problems you’ll run into while developing a product. It’s amazing how many problems in logical flow I’ve found just by creating a diagram of the workflow. Just like spotting an off-kilter cornerstone of a building at the outset will prevent a large number of problems in the future, early detection of program logic can prevent a large number of hazards and risks when you start developing your software.


Showing your stakeholders, investors, or partners how you came to the conclusions you did shows that you didn’t just happen upon your feature set. It gives those people confidence that you are, indeed, running the show and have things under control. When an investor asks you what your plan is, and you immediately send him an email copy of your planning docs, he is going to have a lot more confidence in your ability to deliver consistency in the future. Don’t get me wrong, I’ve seen plenty of plans with documentation who weren’t worth the paper their project plans were printed on. An investor is certainly going to care about a lot more than your planning docs. But it’s going to be a helper if you haven’t built anything for an investor in the past.

Meaningful Buy-in:

We’ve documented the problem we are trying to solve, the approach we are taking to solve the problem, and audience we are trying to reach. We’ve defined our basic needed functionality. We then brainstormed on solutions to our functional problem areas and done some due diligence on what others are doing to solve here. We’ve defined some workflow and perhaps even mocked up some UI to show the experience we are building. At this point, we should submit these documents to your stakeholders and perhaps even some customers for review. Document the responses and get everyone to sign off. You don’t need to actually have them sign anything (unless they are a contracted client and you need the agreement on terms documented for legal purposes). You just need them to see your proposal before you start coding.

Purposeful Pushback:

Since you gained buy-in from your stakeholders and they saw exactly what problem you were solving, who you were solving it for and exactly how you planned to solve it, any changes the stakeholder brings (read: scope creep) can be countered with a discussion about how the change will impact the overall project. You can have a real discussion about how the change may change your approach and how that will affect your functionality. Even if you don’t have stakeholders, this is valuable. If this is just you and some buddies building something in your spare time, you can still use these documents to determine the impact of decisions you make during development.

A Basis for A Test Plan

If you plan to do test-driven development, how would you know how to write your tests if you didn’t know how an operation was suppose to occur? Having your workflow documented allows your testers to create functional tests that iterate on each workflow.

There are a lot more benefits to the documentation you just built, but these reasons are good enough for anyone building a solution to a problem for ANY reason to do the work up front.


In our previous post we described a four-step process to shape the direction of our solution:

  • Define the problem you solving
  • Define the purpose your application will play in solving the problem
  • Identify the audience will you be a hero to
  • Identify the functionality your application will have

In this post, we actually defined and planned our product using a loose methodology involving:

  • Innovation – brainstorming on every idea we could think of to solve for each piece of functionality.
  • Emulation – analyzing competitors and innovative web sites to determine how they solved for various pieces of functionality.
  • Integrate – Combine your innovation and emulation findings to create a set of workflows that will be needed to support your functionality.
  • Authentication – Verify the validity of your workflow by documenting your proposed workflows

I am not following a specific methodology here. You won’t pas a PMP certification by following my advice. However, hopefully these posts can help the struggling technical developer to improve his or her web application, stay focused during the development process, allow him or her to pitch it to investors or stakeholders at any point in the process, and show progress to anyone he cares to (or needs to) show it to.

Feedback is appreciated. I intend to revise this post and keep it updated based on community feedback. Thanks for reading.

I would appreciate if you would tweet, “like” or otherwise recommend this post if you feel it has been helpful. Thanks again!

Building a Better Web Application: Part 1

There are millions upon millions of developers around the world – many are insatiable technical problem solvers. As smart as they are technically, many lack the business aptitude to build a Web application that gets the attention they hope for. This series of posts is intended to help anyone else who is struggling to get from their rough idea chiseled into a popular landmark on the web for a niche audience. In this series, I’m goin to use the premise of creating a fictitious application and walk through the basic steps for anyone willing to listen. To appropriate set expections, you should know that I’m not going to actually build the application in my premise. I’m simply using it as an example because many of us learn by seeing the model first.

Let’s begin!

Developing a Mission Solving a Problem

We’ve all heard about mission statements for sites. Most mission-building is completely and hopelessly bogus! You’re wasting your time, the time of those who will visit your application, and the time of any VC’s you plan to pitch to if you spent hours creating your mission. Stop taking advice from MBAs. Entrepreneur, Garry Tan, defined building a successful business as a three-step process during his Seattle 2.0 Startup Day keynote:

1. Hate The Problem
2. Ship the Product
3. Love the Customer


I repeat those words every morning that I wake up – seriously. There’s no “mission statement” in there. Your mission statement, if you must have one, should be to solve the damn problem! If you are going to spend a large amount of time developing anything (other than the code for your application), spend it on refining and solidifying the problem statement. What exact problem is your app going to solve? If you aren’t solving a problem, my guess is that your app won’t be popular.  Furthermore, if the problem doesn’t wake you up in the middle of the night or otherwise drive you insane thinking about it, then you may not be the person to solve the problem.

When solving any challenge, empathy is king. The ability to feel the pain of others with the same problem will be the driver of passion that helps you beat your competition.

Not all problems are considered important by all people. For instance Facebook solved a social problem. They didn’t solve world hunger. They allowed awkward people to stalk the pretty girls on campus from afar without getting maced. I suppose they solved a few other problems too, but let’s face it – social web apps are popular because we all just want to stick our nose in other people’s business. For Mr Zuckerberg, that was a problem worth solving. With Facebook’s success, who could argue otherwise?

After saying all of this and you may be thinking “If it’s not important to have a mission, why are you talking so much about it?” If you’ve said that, you may as well put this blog away and go back to what you were doing before because you aren’t paying attention. First of all, talking about what you shouldn’t do is important. There are so many MBA programs and certification courses that explain the process of “defining a mission”, [sarcasm]you’d think there were companies who made a living just creating them[/sarcasm]. (In case you didn’t pick up on the sarcasm, there are indeed MANY businesses doing just that.) Second, I didn’t say you don’t want a mission. I just said you don’t want to waste too many cycles thinking about a mission statement rather than investing them on the problem.

So let’s move onto the problem, shall we?

Step 1: What’s Your Problem, Buddy?

Don’t go crazy trying to think up buzz words and find the perfect marketing phrase here. You only really need those eye-catching phrases if you are going to pitch your project to someone else (a VC, another developer who you want to help you, or any other person you want to approve of your project for some reason). Just write your problem statement in plain and simple terms, and then move on.

For the purposes of this blog, we are going to focus on a common problem: “Getting content relevant  to my exact needs through all the piles of useless stuff out there is a pain in the ass!”

“Tobin, that problem is dumb. Everyone and their uncle has solved this problem already!” you may say? Well, let me ask you these questions: Do you have all the content you want? Is it organized how you like? Is it delivered the way you want it delivered and when you want it delivered? This is what I mean by refining the problem. If other’s have “solved” the problem, but you are still not satisfied, then they really haven’t solved the problem yet, have they?

Stepping back and thinking broadly, in this process, you’ll want to define what exactly is bugging you. There is a TON of content available. There are also a TON of sites aggregating or curating content in multiple forms. You’ve got Guy Kawasaki’s AllTop. You’ve got Hacker News. You’ve got Reddit. There are a million sites/web apps out there that will either automatically aggregate your content, allow the community to democratize what you will read, provide you with the tools to point at your own resources or otherwise dictate what’s important and cram it down your throat. Still, you have to think, are these sites getting me exactly what I want or need to know about? How much content do you filter through before finding a priceless nugget? Is the signal to noise ratio high or low with other solutions you’ve found? Think about this problem until you strike a nerve that says, “Damn it! That problem needs fixed and I know exactly what to do to solve it!”

Are we done yet? Not even close.

Sometimes we have more individualized problems. We, as humans, have this ability to pick up a turd, polish it and kiss the hell out of it as though it was your long-lost partner.  If you put your particular “piece of shit” up to the lips of several other people and they kiss it too, then THAT is no piece of shit at all — it’s gold! Do some searching on industry forums. See if others are complaining about the same problem. Set up some searches on twitter for people talking about the problem. Ask around the community what other pain points people are having and see if your problem even ranks up there. Some problems only affect a small number of people. Sure, you can build that solution, but don’t expect to get rich off of it unless you can sell it at a very high price tag.

Once you have your problem defined, refined and verified by others, write it down and move to the next step. For our example, I’m going to define my problem as:

The content that is most relevant to a developer’s evolving needs is buried in a pile of useless material and is never discoverable when they need it.


Step 2: A Purpose-driven Application

OK, you defined your problem and one would think that your purpose is to “solve the problem” as I stated earlier. That’s true, but you still want to define a basic purpose for your web app that explains what you are going to do with that problem. The scope of the problem might be too big to solve it all. You might want to tackle a specific aspect of that problem. You may decide to take a very limited view of the problem and let your application tackle that while ignoring the rest or saving it for later. Let’s go back to the example problem I set above and define the purpose for our site.

The purpose of <x> is to curate the best developer content targeted at an individuals needs and deliver it to a customer how they want and when they want it.

There’s actually a whole lot going on here and I hope you picked up on it.

First, notice that I haven’t given my solution a name yet. That’s really the last thing you should be thinking of now. I just put a nice <x> placeholder in there for now. You can figure out a name that fits your solution once you’re further along in the process.

Second, notice that I emphasis “individuals needs” in the purpose. The purpose I’m defining is to have customized curation and that will require that I cater to individual needs.. There is nothing about customization in the problem statement. But I’m defining how the purpose of my application is going to approach the problem.

You may ask, “But what if I change your mind later?” That’s actually fine. Most companies do evolve and change their approach over time. Amazon stopped being “just a bookseller” and has become a massive retail affiliate as well as a content publisher/distributor. Facebook started off with the “exclusivity” that targeted individuals at Ivy League schools. One would have a hard time arguing that 400 million profiles still provides any exclusivity. You’ll change your site’s purpose, and even the problem you solve may, and likely should, evolve over time. So don’t feel “locked in”. Solve your problem (defined in step 1) now, and iterate as Garry’s 3-step plan intimates.

Step 3: Who’s Hero Will You Be?

You’ve defined your problem, and the purpose your application will play in solving that problem. It’s time to refine who’s hero you’ll be. That’s right. If your problem really is a problem, someone is going to look at your application and say “HELL YES!” and want to kiss you or do other inappropriate things. OK, you won’t be a rock star or anything, but you’ll definitely catch their attention.

Be a hero. However, define specifically who will be the lucky recipient of your benevolence. You can only help so many and you want to treat them like GOLD. So keep refining until you have an audience small enough for you to be attentive to.

In our example so far, we have mentioned that we will be targeting software developers. That’s the extent of our refinement so far. This is a VERY large group and you’ll want to start off targeting a smaller group. “But, I want a large audience so that I can maximize profits!” is a common response. Your not going to be able to serve that large audience. You can’t LOVE THE CUSTOMER if your customer pool is so broad that you can’t empathize with each of them. Trust me, if your application solves a significant problem for a niche of an audience, you’ll grow your application to serve more people over time and hopefully you’ll hire people who can empathize with the larger target market. When we defined our purpose, we defined the approach that we would take to solve a problem. A professional developer and a beginner developer are likely going to need different approaches in order for your application to be their ideal solution. So in this step, we are going to refine this audience to the group that you can empathize with most. In my example, I’m going to add the following refinements to the developer audience:

  • Professional and experienced
  • Standards-compliant web developers
  • Passionate about the field

For my example, I’m stating that I am going to target developers who are professionals. They have been in the business a while, know the terminology, understand the landscape of development, and really just want to find content that keeps them up to date. This reduces the need for me to spin cycles explaining basic concepts like dependency injection, SOLID, DRY, etc.

I’m also going to target standards-compliant web developers here. I’m not going to concern myself with telling people how to write code that works on proprietary systems. To support a customer trying to do proprietary things means I have to learn about their system first. I don’t have the bandwidth for that, so let’s focus on the standards that we all know and love.

I’m not going to try and convince people to be passionate about development. My audience should already have a passion for development. This reduces the need for me spin cycles “selling” the content. It should sell itself.

Notice how each of my refinements were focused on excluding people from the larger pool I originally selected? These refinements were also meant to reduce the amount of time I’d need to spend catering to the audience. You should add those refinements until you feel you can speak to the hearts of those you intend to serve.

Step 4: The Broad Strokes

So we’ve defined a problem, explained the purpose our app has in approaching the problem, and have defined who’s hero we’ll be. Sounds great. Now we need to understand the broad strokes of functionality we will provide within our apps purpose for living. We aren’t diving deep into features yet. That’s a bit premature. We are talking about the broad feature set rather than the implementation details at this point. For instance, if I were designing the first car ever made, I might pick the broad features like “go”, “stop”, and “turn”.  Much later in the process, I would likely define that I should be able to “go” both forward and reverse or maybe even sideways. I would also later define mechanisms like a gas pedal, break pedal and steering wheel. For now, we’ll just stay with the broad strokes. You might write them down like this.

  • Low-Barrier Community Contribution
    • Let’s not worry about what all they can contribute yet
  • Rewarding Community Interaction
    • Interaction Let’s not worry about what kind of interaction yet
  • Compulsive Browsability
    • Let’s not worry about what pivots we can browse or otherwise filter content on just yet

    Now think it through. Do these broad strokes solve the problem you defined?

The content that is most relevant to a developer’s evolving needs is buried in a pile of useless material and is never discoverable when they need it.

Well our first bullet, “community contribution”, allows for developers to vet content that is submitted by others. The community interaction could allow for the developers to further refine what content is good and what is bad. Compulsive browsability means that the content is so easily discoverable that you can’t stop browsing – like when you get stuck on YouTube or LiveLeaks watching videos all day. That ultimately takes me out from under the “pile” of useless material.

So now that you’ve written down your basic functionality, and aligned it to your problem, you’ve discovered that you don’t completely solve your problem yet. This is a good thing. You’ll want to add or remove some broad strokes until you feel that your problem is solved.  I’m going to add the following additional functionality:

  • Personalization
    • To fit the evolving needs of an individual, you’ll need to have some sort of personalization. Let’s not worry about what personalization yet.

    Next look at the your purpose:

The purpose of <x> is to curate the best developer content targeted at an individuals needs and deliver it to a customer how they want and when they want it.

Does your application meet it’s purpose? We are going to curate the best developer content and target it at individuals needs. But we haven’t talked about delivery yet. Are we just going to deliver through a web page?

IMPORTANT NOTE: According to an article on tech crunch, time spent on Mobile Apps has surpassed time spent web browsing.

You would be wise to consider the fact that you need a mobile component. Also, there are thousands of feed readers and aggregators already working for developers on some level out there. Wouldn’t it be wise to provide data in RSS? Let’s not dig into the specifics of the implementations we’ll provide delivery through just yet, but we need to define the broad stroke of this functionality so it isn’t missed.

  • Diverse Delivery
    • Again, let’s not define all the implementation details of delivery just yet.


We’ve actually done a lot in very little time. We’ve defined a problem that get’s us up in the morning and the middle of the night. We’ve defined the purpose our application will play in solving the problem. Furthermore, we’ve defined who the people are who will find our approach most rewarding.
We have now defined the foundational broad strokes our application needs to provide. We’ve further expanded on those broad strokes in order to solve our problem with our application’s purpose in mind and with our audience in mind too. As a result we have five broad swaths of functionality we need to provide.

Note: This is part 1 of a series of posts on building better web applications. If you wish to continue, please read part 2:

Feedback is appreciated. I intend to revise this post and keep it updated based on community feedback. Thanks for reading.

#MIX11 Day 2 Impressions

Yesterday was the second official day of the MIX11 conference. It was quite clear from the audience reaction that the second keynote was far more interesting and appreciated than day 1. There was an energy in the air that was palpable.

Customers seemed to love each and every part of the keynote — from the virtual 3D ScottGu to the Blue Angels web site being developed in HTML5 and Silverlight. The applause was thundering. I encourage you to go check out the recorded keynote here:

I had a lot of fun talking with developers from all over the world about what they were working on, what they were interested in seeing at Mix and what they thought about the conference so far. I’m always amazed at how inventive our customers are with our software. More so, I’m always happy to see the passions that come out when geeks of various walks of life come together to talk about the field of software development.

I also had the opportunity to watch the Channel 9 booth live as Miguel de Icaza sparred with Scott Hanselman about open source development. The laughs were frequent but more importantly, I think developers had the opportunity to see different views on the same community by both of these dynamic individuals.
I attended the “Future of Windows Phone 7″ presentation to see all of the fantastic features we are adding to the “Mango” release of Windows Phone 7. The list seemed endless. The presentation was literally an hour long presentation that listed the features of the phone that were coming up without much deep dive. From being able to take screen shots to having direct access to the hardware sensors, to the inclusion of new sensors, the list was amazing and should make for a great update to the Windows Phone 7 developer story.

Just as I did the day before, I spent breakfast speaking with developers about what they saw in the sessions the day before. Kevin Griffin said that he attended the Deep Dive into HTML5 and Graphics/3D with Silverlight 5. He said that he enjoyed it, but “it was like watching a DirectX or XNA 3D talk for the first time.” Apparently he felt the session level was misidentified as level 300 when the content was actually level 100. Kevin also said that the HTML5 Canvas discussion proved that it was “tedious to do cool stuff. We need good tooling in order to do that stuff right. Browser support is wonky.” He was referring to the disparity of support between each of the browsers. Of course I’ve known Kevin a long time and I couldn’t resist ribbing him about his new acquisition of a Windows Phone 7 device. He picked one up yesterday and just started learning to develop. I jokingly asked him what was taking him so long to develop his app. “Most good developers I know can have an app ready to submit to the marketplace within hours of getting their device. What’s your problem?”. Of course Kevin is no slouch and he immediately responded “well, I keep trying to use MSDN to learn how to develop my app — that might be my problem.” Yeah, Kevin can give the barbs as well as he can take them.

The MIX11 attendee party was apparently “successful” in all senses of the word last night. I was unfortunately unable to go as I’ve been sick all week. I took this opportunity to rest. Based on the looks of the crowd this morning, they didn’t let the party affect them too much. They all seem attentive.

I’m looking forward to this last day of presentations. However, the MIX11 experience doesn’t end when I get on my flight. We will all be able to “attend” the presentations at Mix online when the session recordings are posted at

Thanks for reading!

Day 1 #Mix11 Impressions — From the Customer

I had the opportunity to sit down with a number of MVPs last night and this morning at breakfast to discuss what they learned at the Mix conference on day one. I wanted to get a sense for what we were doing right and what we needed to improve upon. I thought I would share those thoughts with the public and ask for your input. If you are at the conference, feel free to find me and give me your feedback or leave a comment here and I’ll be glad to start a dialog with you.

Last night I spoke with Dave Ward in depth about his experience. He spoke overall positively about the conference. He said that the keynote wasn’t as exciting as he would have expected but he was overall really pleased with the conference. He attended a breakout session titled “50 ways to speed up your HTML.” He said that they actually covered 57 tips in the session time which is amazing. Dave said that the session was awesome and that he learned at least 2 or 3 things. I laughed and told him “You do realize that leaves you with about a 5% retention rate, right?” Of course he said that he knew a lot of the other things that were discussed but that he was overall very impressed with the quality of the session.

VanThis morning I had the opportunity to speak with Van Van Lowe about his experience with the conference. He said that he too was very happy with the conference and that Mix is his favorite. When I asked what he liked most about Mix that he didn’t see at PDC, he indicated that he enjoyed the web focus because he is a web developer. Strangely enough, I met Van at PDC 2010 while talking with Scott Hanselman. Needless to say this guy gets around to our conferences! Van attended the Orchard breakout session because he said that he has big plans to use Orchard. Van said that he got enough out of the session to get him started and that was basically the point.

I attended the Orchard Session yesterday as well. I was surprised how far this project has come since I blogged about it so long ago. I am good friends with a former developer, Erik Porter, and a current developer, Nathan Heskew, on the Orchard project. Talking with others who attended afterward, they seemed extremely pleased with the progress and many said “this is ready for prime time and it’s so much better than anything out there right now.” and “They’ve thought everything through.”

I’m looking forward to the Mix day 2 keynote just about to start now! See you there!

#Mix11 keynote rolling along.

Sitting in the darkness of the Mix11 keynote with only my Windows Phone 7 i can see the excitement around the IE presentation. We’ve seen some great IE9 demos and seen some hilarious videos. What will come next? The audience is watching intently as we just announced we are 3 weeks into the development of IE10. More to come.

Posted from WordPress for Windows Phone

Why Didn’t You Come to Mix11?

As mentioned in my previous post, I had the opportunity to talk to a number of people — some on twitter, some in person and some even on my way to Mix — about why they didn’t come to Mix.

The responses from the community were very interesting. Of course, I received some very useful and some very comedic responses on twitter.

In response to my query about why some wouldn’t come to Mix, @ardalis responded, “You’re looking for a list of 6 billion people not going to MIX?”. Touché my friend. I wasn’t looking for EVERY reason some were not attending this year, I was looking to understand what regular conference-goers and community-influentials were not coming and why. Here are some of the main reasons I received:

I’m Working!
Many of the individuals who responded were too busy working to take time off and come to Mix. @brheal said “Wish I could be there! Always falls at the end of tax season (tax software developer).” I thought this was a one-off but I soon received another response from my friend @pmourfield who said “I wish that #MIX11 didn’t fall during the last week of tax season. So wishing I was able to be there!” Apart from tax software developers, others are just too involved with their clients. @mranlett said, “I didn’t make it to #MIX11 this year. Busy satisfying client needs & working on proposals for future work w/future clients.” And of course @dpenton stated that “I have too much work happening right now.” That’s completely understandable on all accounts. I wish you all could be here too.

It’s too Expensive
My friend @akcoder isn’t coming because, in his words, “I am not going because I’m saving my travel/conference budget for PDC.” It seems understandable that most of us have to pick and choose where we spend our money and pay for conferences where we see the most value for our needs. Yet another long-time friend and Microsoft MVP @sarajchipps told me “I’m not, because it is waaaay too expensive for an independent.” When pressed as to what value would be appropriate to make it not so expensive, Sara indicated “That’s a great question, I would want to go to talks and events… I could live without the food and amenities.” She went on “my budget is usually around $500 for a pass when it comes to conferences.” At further prompting and discussion amongst others in the community said “I’ve pretty much gone without MS conferences this year. Last year I was given a few passes, but $1500+ isn’t at all feasible.” It would appear that some of the independents are feeling the squeeze on financial resources. Of course @robwindsor had a solution “Mix should have something like TechEd Exhbit Hall pass ($100). Gets you into Commons and Connect lounge”. That’s a fair point and perhaps we can give that feedback to the folks running Mix. I have it from the rumor mill that Microsoft already loses money at the conferences, but you never know if something like this is possible. This seems to be overwhelmingly more important considering the number of responses in this category. @simonech said that he “cannot afford 2 flight[s] to the US in less than 2 months (been at mvp11)AND ticket + hotel/flight could be off budget for my company.” Truly we must all pick our battles. Response after response from this point forward seemed to point to the cost of the conference — either the cost of the conference itself, or the complete cost after hotel, flight, food, ground transport and of course the conference.

So why haven’t you come to the conference? Why did you come to Mix this year? What did you hope to get out of the conference? Alternatively, why didn’t you come this year? What is competing for your time/money? What would make the conference most valuable to you?

Thanks for reading. Stay tuned until later on this morning when I cover the keynote presentations!

I Have Arrived … At #Mix11 that is

I have just landed and got my bags rather quickly. I’m standing in a rather long line waiting for a cab in sweltering heat (comparatively speaking that is). I have been reading tweets from those who have been here and already joined in the excitement — from Scott Hanselman tweeting about his rehearsals to random conversations I started with those who couldn’t make it. The anticipation is killing me but one thing is for sure, I have arrived at Mix!! The cab line is filled with chatter about design, development and plans for a geek-long getaway. I brought my trusty Nikon D-7000 which at this point weighs a ton on my shoulder. I’ll be sure to put it to use and give you all regular updates. Stay tuned!
Posted from WordPress for Windows Phone

On My Way to Mix11

Be on the lookout for new posts this week. OK, this is really a placeholder post for the “mix11” tag I just added. Move along now. Nothing to see here. 😉

PMing my Technical Skills: a guide to ramping back up technically speaking

I’ve been transitioning away from a solely technical skillset to a PM skillset at Microsoft for a while now. That said, I have found that personally, I prefer to still keep my technical chops. Why should I have to sacrifice one for the other? My love for the technical world should drive my passion for the PM role. In fact, I’ve now found that I’m using my PM skills to compliment my technical skills as well.  I don’t mean to say that I’ve applied all of the PM principals to my technical studying. However, I have realized that I inadvertently used those things I’ve learned in my PM career in a very lose way to help my technical skills.

Competitive Analysis

I like to see what other people are doing. Not just from a purely social standpoint, but also to understand what skills other’s find valuable and easy to use, and what skills are most common among everyone. I often also cruise the job boards (Microsoft Career Site,,,, etc). I tend to look in various places around the country just so I know if certain skills are hot in one area, but not in another. So, I composed a spreadsheet of available positions, skills required (soft and technical), optional skills, pay, benefits, region, etc. I don’t do this because I’m looking for work, I do this because by gathering enough information, I can find that jobs that require iPhone app development skills pay more than say, Silverlight development skills. Once I had this data, I could see what skills were most valued. This serves as a rudimentary competitive analysis or “potential performance” and represents part one of a good gap analysis.

Skill Inventory Assessment (actual performance)

Part two of creating a good gap analysis, involves determining your actual performance to compare against your potential performance. To do this, I find it useful to also look at what skills I have in my inventory, see where they intersect with my “potential performance” from above, and see if I somehow missed your other skills as potentially valuable in the market. So, I made another sheet in my spreadsheet to list skills that I had and the self-assessment level at which I rank myself. For any skills that I added which were not in my “competitive analysis”, I did further research to see if those skills were found in the job boards or on friends blogs, or anywhere that I could assign some value to the skill. I use this as a secondary sanity check for skills that I might need to beef up on. Once I had this done, I moved on to the actual gap analysis.

Gap Analysis

I compared the competitive analysis against the skill inventory assessment and came up with a reasonable gap analysis of skills that I either needed to improve or acquire, and a list of other skills that I had which I needed to deemphasize in my studies for the next year. This list represents the gap that I have between where I want to be and where I am – otherwise known as the gap.

Action Plan

Once I had a my gap analysis complete, I had to create a plan to get from point a to point b. I looked first at books. While many people don’t learn well from books and prefer other methods, I still prefer a good solid technical book at least to start, and then I move on to other resources. So, for each skill, I set out to collect a list of books for each skill area on amazon. To assess each book, I looked at the number of ratings, amazon ranking, average rating, release date, and a number of other factors (including glancing through the table of contents to see if I felt those skills would be adequately covered in the book. Once I had the list of books, I didn’t stop there. I created a new sheet in my Excel file for each book that I intended to purchase. I listed each chapter and it’s length so that I could determine how fast I could read each book – giving myself milestones to complete by certain dates for each book. I made sure to account for downtime, upcoming vacations, goofing off (all work and no play…), and various other factors to give me a reasonable burn down rate on my learning plan.

Prioritizing the Plan

This is one area I thought about for a while. I could simply make this all about money and learn the most valuable skills first. However, I like to have fun, and I have specific projects in mind where some of these skills could be put to good use. That said, I opted away from prioritizing in any way that would be meaningful to anyone else. I am my own customer and I think it’s fair to let me set my own priorities in this instance. For others, however, you might want to prioritize based on projects you have at your job, getting a specific job, or just for pure fun. The option is yours.

Metrics / Performance Analysis

I’ve set clear goals for what I want to accomplish and set a timeline for completion. I have milestones that can help me determine my progress and help me assess risks. I have a project calendar and a burn down chart. I stopped short of creating a project file or creating work items in TFS. I’ll just use my spreadsheet to keep me in check for now.


This obviously doesn’t represent solid PM work, but I realized after the fact that I had just done a great deal of the same type of work I would do when I start a real project. It’s easy to say that you need to pick either PM or Development, but I’m finding that skills from both disciplines can compliment themselves quite well.