Project 1: New Task Management

Task Management has always been an interesting challenge for me. I tend to involve myself in a lot of different projects of varying fixed priorities, each of which tend to spawn tasks at a rather alarming rate. The issue is not so much keeping track of what the tasks are, but knowing the best order in which to complete them to maximize my time and efficiency. I can't venture a guess as to exactly how much of my time is wasted through my inefficient task management practices, but I do believe that it could be substantial, and am intrigued by the proposition of building a solution to this problem (as I feel others might share it).

The idea is relatively simple. The user creates a series of queues tied to real world sources of tasks with fixed relative priorities. For example, whatever your main project is has the highest fixed relative priority, your second most important project has the next lower priority, etc. Low priority things, such as spare time projects, have relatively low priorities compared to the others.

Tasks in each queue are then rated by their importance. "A" importance tasks are things that are absolutely essential and must be completed prior to any of the lower importance tasks. "B" importance tasks are tasks that are important, and given time can become "A" importance tasks, but are generally less pressing than the "As." "C" importance tasks are lower still than "B" importance tasks. "C" tasks typically do not escalate, and are not particularly time sensitive.

Tasks from all the queues are then aggregated and abstracted into a single task list. The "A" importance tasks from the highest priority queue are obviously first on the list. The "B" importance tasks from the highest priority list may or may not be presented next based on rules and preferences. For example, if your second highest priority queue has an "A" importance task, this may appear before your "B" priority items from the "A" list. This is how the task list is generated.

Tasks could then be stripped from the list and automatically scheduled into indicated "task time" blocks in your schedule. Each task, when entered, is provided with an estimated contiguous time required to completion value which can be used in conjunction with a bin packing algorithm to fill your schedule.

There are a few ways in which this system would be helpful.

1. tasks would not as easily fall through the cracks for lower priority projects
2. time would not be wasted on low priority projects if there are pressing issues with higher priority projects
3. you gain a dashboard on your potential productivity, and can appropriately shift the priorities of your tasks to optimize timing based on external requirements. You know how many of your tasks from each of your projects you will likely complete in a given time period, and which ones you will complete.
4. reduced workload from an additional queue helps tasks which would normally starve reach the top of the queue and get completed during somewhat unexpected or unpredictable lulls in timing
5. automatic task priority escalation based on a fixed elapsed time period helps keep long run low priority objectives on track when they might otherwise be lost
   

This could be built as a web app, and tied into software on mobile devices such as blackberries or iPhones, as well as cross connected to web based calendar services. If you want a profit motive, I think people would pay an access fee for something that would allow them to be more productive, particularly in a down economy. There could be some interesting group management implications for this system as well.

Estimated Project Parameters for Initial Prototype

Design Complexity: 10h for partial prototype specification
Code Complexity: 8h for exploratory prototype implementation
Team Requirement: 2-3 integrated designer/developer(s)
Competing Products: Many in the space of task management, but none quite like this one
Potential Benefit: Participant Dev. Exp., Participant Design Exp., Useful Tool Produced, Potential Marginal Commercial Benefit, Potential Incidental Tech. Dev.
Potential Risk: May be Worthless, May not Work as Intended
Status: Committed, Team Recruited, First Sprint Scheduled, First Prototype Live

Weekend Projects: An Introduction

An important part of what I hope to do with this blog is coordinate the creation of more Weekend Project teams. A Weekend Project has a few functions.

• they have the potential of producing either a workable product, or a tangential technological development which might yield some value
  
• they provide useful knowledge and experience in creating and maintaining cross functional product design/development and software implementation teams, which again, provide commercially valuable insights
• they are excellent opportunities to get to know and work with people in an informal setting which might or might not result in a serious project. Over the course of working on a weekend project, even one that does not succeed, participants gain a good sense of eachothers individual skills.
• they are fun! Fun projects are often good for quickly and inexpensively attracting groups of test users, developers, project leads, etc. boring projects are an exercise in futility
  

In order to facilitate the efficient operation of such a team, it is essential to consider first and foremost how the value created by the team can be captured. If the value cannot be captured, then everyone involved is just wasting their time. It is also important to remember that the value created does not necessarily have to be monetary. Someone gaining the experience of running a development team can be a form of value capture, as can the process of creating thought experiments, product design concepts and documentation, as well as tangential technological developments. Of course, the interpersonal and team connections made also have significant value. These are some of the weekend project axioms that I have come to believe in:

1. Document Early and Often. People working on weekend projects must look to document and share their thoughts and insights in a cooperative and constructive environment before they try to implement or test the ideas in software. Ideas are amazing in their flexibility, and tendency to multiply when given the proper conditions. Not only can more invention be fostered by focusing on documentation, but more of the insights can be captured and preserved as a part of the process. Our memories are all terrible, we should not depend on them nearly as much as we do.
2. Rapid Development. Weekend projects are by their very nature rapid development projects. The team is comprised of a group of passionate volunteers looking to get something valuable out of the project or experience. This individual objective can only be satisfied if the entire group works together in pursuit of their common selfish interests. If these types of projects lose even a little bit of momentum, they will crash and burn almost overnight. Therefore it is important to keep the pace of progress high, and keep people's individual ambitions in mind when planning out sprints.
   
3. Create Functional Self-Organizing Teams. Self organizing teams are not hard to find or form. The real challenge is preventing them from becoming social clubs rather than development teams. To keep this from happening everyone on the team must feel as though they have two things (1) a vested interest in the project's success and (2) the ability to make a unique contribution to the team. Simply put, people need to need eachother to work together efficiently as teammates. If this cycle fails, the team will fall apart.
4. Stress Individual Contributions and Leadership. Volunteer weekend project groups are "awesome" because everyone involved can exercise a passionate interest in something. It is typically very easy to find additional members to work on these types of teams once a project is underway (relative to hiring a full time employee) which means that there is rarely as much risk in putting someone in a leadership position as there can be in more traditional settings (so long as axiom 1 is followed). However, noone can feel as though they are being unnecisarrily restrained by a project that they are working on voluntarily, or they will quickly work on it no longer.
   
5. Build a Culture. Tiny teams often have big culture. Artifacts and processes are important, and will live and die at the drop of a hat within a tiny ecosystem. The culture at the ground level on volunteer projects is the glue that keeps everything stuck together when people's individual interests wane (no one is 100% for 100% of the time). This type of sticky stuff is absolutely essential to success.
6. One Leader per Project, One Project per Leader. In the end someone always has to 'own it.' You can never help the fact that there is always a single individual person who has more invested in a project's success than anyone else does. These people should lead whenever possible. It is also critical to ensure that the leaders do not get burned out through overcommitting to too many projects. Too many cooks may spoil the soup, but conversely too many soups may spoil the cook.
7. Be Critical of Others. These projects are first and foremost opportunities to learn and capture individual value. This purpose is not served well if everyone bites their tongues in order to save each others feelings. If you want to learn from your team, you have to communicate with them. Barriers to criticism should be torn down as early on in the project as possible, or they will quickly become impenetrable.
8. Know when to break the rules, and do so with confidence. No human endeavor has ever been so well understood that it could not be improved upon. These axioms are no exception. Knowing when to walk away from the plan can be as important as knowing when to do it by the book. The only thing worse than not recognizing when you should break the rules is realizing that you should and choosing not to.
   

QN #1: UI Design and Lead Users

One of the more interesting classes for me this semester is "Developing Breakthrough Products and Services" with a guy named Eric von Hippel. He focuses heavily on user innovation in product development, with a particular eye towards hacker and open source communities that I find both refreshing, and fascinating in an informed academic setting. Asside from the fact that this course is the anit-mater to my "Managing Innovation" course (wherin all development is the result of carefully structured corporate investment) I have also encountered a few sticking issues that bother me. One of them is that lead users are not the holy grail of product development either; there is at least one thing that they do continuously badly: UI Design.

Lead users are bad at interface design, because they develop interfaces that make sense to them, te informed lead user who is trying to do something that no one has ever tried to do before. They already understand enough of the context that the few additional pices of information that are relevant to them and their interactions are obvious and trivial. This also makes it very difficult to convince them that anything needs to be changed, as it is already "easy to use" even if noone else can use it (after all, it makes sense to them).

Lead users, it is said, are each working to scratch an individual itch. At least, this is often true in hacker communities, or it is often cited as a potential motivation for them to engage in their engaged activites. Again, however, once the itch is scratched there is very little incentive to re-invent the wheel in terms of improving the interface.

Further, lead user groups are typically dominated and controlled by respected influentail contributors, the "olde timers" of this sort of a world. These individuals hold some power in terms of making community oriented decisions (which design ends up being) and can steer the progress of UI development in the direction of standards which fit with their perspective on what users should be able to efficiently interact with.

If we imagine a typical normal curve, the lead users are isolated in the left tail. The most extreme case, the single user case who develops a particular feature, the UI is essentially only useful for them. Community pressures eventually push the design to the point where it meets the needs of a majority of influential lead users. However, the issue still remains that lead users are strange, and what they agree on as a group is often significantly differnet from what "normal" users would find easy to interace with. Thus, I propose that there is a gap between the majority of influential lead users, and the "normal" people located in the majority section of the curve. I like to think of this as the "linux is hard to use gap" because, after all, on the surface it is true: linux is hard to use when you're coming from a Windows or Mac environment.

This problem can be addressed by developing traditional marketing exploration procedures to existing lead user products in order to bridge the usability gap.

Manifesto

Every time I start a blog, I feel the need to open with a "manifesto" ish post wherein I attempt to explain the purpose of the publication, and what I aim to get out of writing it. This blog should be no exception.
As some of you may or may not know, I am currently a first year student at the MIT Sloan School of Management. My background is primarily in Software development, having worked on a number of both Academic projects and Commercial projects during my time as an undergraduate. During my time at Trinity College in Hartford, I founded a small software development firm which focuses primarily on developing cluster scheduling software. We also have been known to work on a number of other projects where low overhead due to our existing assets coupled with a small amount of up front effort to go to market have provided a few financial opportunities.
The function of this blog is to, agian, (as almost all of my blogs do already) function as a sort of bit bucket for ideas that I come up with or thoughts that I have which simply cannot be squeezed into my day to day life. I have already done this a few times with my musings on tech and economics. This blog is about product development. It's specific focus is on bootstrapped projects, accidental innovation, and things that make good weekend endeavors. I am all for forming small groups to explore new ideas, and have far too often been frustrated by how difficult it is to efficiently capture all of the cool things that these groups typically produce. Hopefully I'll also be able to advertise a few groups and projects on this blog in order to attract other people who might be intersted in forming some simple teams.
I'm going to also post periodic notes and such just based on my own product development musings, which will hopefully prove somewhat interesting (at the very least, they will be interesting and useful to think through while writing).
This more or less captures the general point of this blog. I am anxious to follow this post up with one about an actual product development aspect that I have been considering during the day today.