Product Development with a team and Flash

For today I would like to discuss the important of a “Product” vs software consulting, and how that can lead to different requirements/focus. If you have worked as a consultant developing applications for a specific client, generally the most important item is usually to meet the requirements, and make sure the application works well. Although this on its own is important, when you are developing a “product” there are other factors that suddenly become important. I have found developing products to be truly an enjoyable challenge.

Here are some things that are good to keep in mind, these are general points. I will be posting more details in later entries

  1. Maintainability: It needs to be easy to maintain or else you will run into a nightmare long-term. Although when developing any piece of software, you want to make sure it is easy to maintain, when developing a product it’s even more crucial as support costs can kill you (you can’t always charge for support), while in the consulting business you can charge for support costs. While in the consulting business you weigh the upfront costs to the client of making the product maintenance free versus performing maintenance as needed under a support contract–the latter option is often more cost effective in a single-installation scenario.
  2. Architecture: When developing a product the architecture becomes much more crucial. It needs to survive the test of time, needs to be very reliable, and needs to be flexible enough to meet multiple client requirements, usually from a single code base. You no longer are building something that one entity will use, multiple clients will use it and will have different needs from the same application. Being able to achieve this goal is not as easy as it sounds. Also, make sure to keep in mind that although you usually start from one initial client need, the long-term goal is a product to be used by multiple customers. Depending on your application this might be easy or might not. Flash contains many issues that you will run into that I will discuss in other entries. Also there will most likely be some growing pains if you have never worked with such goals
  3. Team Consensus: Everyone on the team needs to understand that what is being worked on is a product, if the team has always been a product development team that is usually not as much of a problem, but for consultants who are transitioning into building products, usually you have to hammer in that fact a couple of times for people to get it
  4. Planning: Planning the development process becomes much more complex and crucial. You need a lot more thought into design, timelines, release plans, feature-set, and general product path. Not only do you need this for the developers, but you will need it for the marketing/management department and clients. Many clients want to know where the product is going before they invest heavily in a product.
  5. Commercializing: When developing a product you have to think of things like marketing, solid documentation, and dedicated customer support team.
  6. Reduce manual work: Many times when working on a consulting project, you are only interested in deploying to one server, with a single configuration, and single client. This makes the process of installation, configuration, monitoring, maintenance, and updates a minor task in comparison to the development process. When you have multiple clients with a single product though, being able to easily install, update, etc becomes important as you can easily end up taking up more time than the development process itself. This obviously depends on the complexity of the application you are working on, for us the application involves 10 or so technologies, multiple platforms and a bunch of hardware integration. For application with less complexity this is not very difficult of course, but still just as crucial.

4 thoughts on “Product Development with a team and Flash

  1. Me too. We’ve produced an elearning product built in flash that’s about 2 years old now.

    From the start, our product has been designed with a very broad customisation layer, so that we can deal with client needs that would generally be handled by a traditional software consulting model.

    It’s basically a hybrid of the two approaches, and has a whole other set of issues especially with documentation and how far we allow customisation to go, but we seem to be able to manage it.

  2. Hey Chafic,

    I would like to add (or to be precise “insert” 2 more items at the top of your list):

    1. User experience first. We found it to be very useful to start designing an application from the user level. Before your diagrams are drawn or the interfaces are defined, ask yourself the following questions: What is the most convenient way for a user to use feature A. How many steps would a user need to make to get task B done? How can you simplify it even further? I believe product architecture is an after step from the “user-experiece design”.

    2. Ease-of-use. I believe it is absolutely imperative to set the ease-of-use as an overall goal for your product. If you manage to achieve the uttermost simplest way to get things done in your product, it will go ways to make it successful. Most of the times it would mean introducing and hiding that extra complexity from a user. For instance, if your competition requires 5 steps to get a task done, and you manage to collapse it to 1, you are ahead of your competition and users will love the new simple way to do things.

    cheers,
    Joe

  3. Hey Joe,

    I agree big time on your points. They are both things that are very important. I think it usually depends on the company though. The user experience tends to be something “Flash” guys care about more than traditional developers. Times are changing and its becoming more and more a business requirement, but its just something I noticed.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>