While having tea with a friend yesterday, we ended up discussing a mobile application project that he’s been working on. He had been on the project for over a year and in inquiring about the readiness of it, I learned that he needed to do quite a bit more. Part of the issue was that the angel investor he’s partnering with has this desire to continue adding features, many which doesn’t seem necessary for a near term release. As we continued talking about the features and as he demonstrated what his application was capable of, I realized that I saw a pattern in how many non-developers end up treating software products and wanted to create a post to hopefully help non-tech people who want to develop a successful product based on my own experiences of failed and successful launches.
One of the dirty little secrets in tech that really isn’t a secret is that most ideas for applications are not original but derivatives and a slight enhancement to an existing application. Some people feel that products need to be groundbreaking and completely new to be able to compete in the market. The reality is that software products usually will never be that groundbreaking and only offer incremental improvements to a saturated market.
But this notion is perfectly fine because the true reason for developing something “new” (not necessarily original) is to improve upon something that is severely lacking. At the very least, the product must have features or capabilities that are 10-20% better than anything existing. Features that usually should improve upon an existing product can/should include price point, security, user interface, speed, and reliability.
I tend to think people worry about timing more than anything in markets. Marketing ends up pushing things to meet certain goals whether it’s to show off the invention at a conference, beat the competition by producing something to market before others can, using numbers/trends in the market to dictate when a product is released. As a result, usually what ends up happening is the “overpromise/underdeliver” scenario whereas as software people we are taught to “underpromise/overdeliver.” In turn, things end up becoming extremely messy as the marketing/sales teams end up dictating the delivery of the product rather than the people building it.
This is a horribly ass backwards way to go about doing things.
In fact, I argue that in my experience a great deal of failures occur in product launches as a result letting marketing/sales drive things rather than product/software people. Here, a huge issue is setting up proper expectations. Then once the product is delivered things break, is slow or just doesn’t do what people want because it gets rushed out based on features that usually get blown out of proportion without control. What’s really needed is a proper SDLC (software development lifecycle).
Any decent software engineer should understand what the SDLC is and hopefully has some exposure to it. Any good to great software engineer should demand it at the company they work for. The SDLC isn’t really a specific process like waterfall, agile, etc. but a general process to help keep a software project on course. The SDLC should be customized to fit the project, people and culture of a product/company. For instance, start up companies should use a light SDLC while a company that requires audits, heavy controls, etc. should use a multi-level SDLC. At any rate, the SDLC should be consistent although it can adjust overtime to accommodate the needs of the product/business.
At the very basic level, the SDLC should provide engineers a sanity check while giving the business stakeholders high level insight into the product. The sanity check for engineers for me is one of the biggest keys in all of this. The way the sanity check works is by providing deliverables that the engineers can use to thinking about how a product can/should be built.
At the very least, the engineers absolutely need to know what the software product is. Believe it or not, this part is one of the hardest things to extract from the product owner because most non-software people who envision the product tend to have very vague ideas in what the product should do. Worse yet they often times never can put these ideas to paper. Without something written down, engineers on average have a near impossible time implementing the vision.
Usually, what an engineer needs is something called software requirements. Software requirements are the parameters on the behavior of what the software ought to do. They provide a framework that specify exactly how something should work. It should never be polluted with technical details because that aspect can only be taken into consideration after the basics are defined. But some simple examples would be the behavior of the application when a user clicks on a certain button. How does the application respond? Do it provide some sort of user feedback via a visual message like a popup box? Does certain data get saved some place? Are there any constraints on the data that needs to be saved such as the maximum size of a description box?
The more details the business owner can provide, the better idea the engineers can have in determining not just how something will be built but the difficulty level, the feasibility and the time it will take to create the features. Some methods like Agile have very specific ways to handle this, but I’m leaving those discussions elsewhere. The main thing is that once these requirements are defined, a good product/project/software manager can work with developers on defining the scope of a project.
Scope essentially is figuring out what can be delivered for an iteration. A solid engineer will understand based on well defined requirements their output level on a per requirement basis. A good project manager will understand how to take the input of an engineer and create a priority list juxtaposed to the effort level for a feature. A good product manager/owner (and other stakeholders) will be able to examine this list and decide what goes into the current iteration. Once a sign off occurs, those features are locked in.
Generally, what happens in most projects is a behavioral anti-pattern called scope creep. Scope creep introduces new, unestimated features that mangle up iteration timelines because it moves the target of the agreed upon date further up. You want to avoid scope creep at all cost because uncontrolled scope leads to an undelivered product. The problem here is that scope creep is like drug addiction; once you get into the habit of using drugs, you’ll want more. Software engineers on average never want scope creep; they like being able to focus on agreed upon deliverables.
The only exception to scope creep really should occur when an unforeseen disaster could happen. That might be incorrect definition of a requirement, security hazard, a show stopper bug that came up through poor design. Either way, when scope creep does occur, the main thing here to understand is that the target date has to change as well because the change must take into account new estimations.
Now, I’ve mentioned the keyword iterations a few times now. Iterations are points of release for a product. They take the features defined in the scope and push them out within a timeframe. Because of how traditional software has been perceived in the industry as being static and how the web has changed the way software is delivered, many people still have deep trouble grasping the idea of an iterative process.
Iterative processes are about the continual improvement of a product. In the past days of packaged software, once a piece of software was delivered to the hands of the customer that pretty much was it. Prior to the internet, if a piece of software had bugs, there wasn’t any easy way to update it. For enterprises they would hire the support staff of major software venders to provide fixes (and still do). However, the internet allows for patching or on the spot updates when it comes to websites. In turn, people need to get rid of this idea of packaged software that needs to be perfect out of the box.
The iterative process allows for the continual improvement of software. So you can never expect a piece of software to go out perfect anymore. What’s more important is releasing something as soon as one can and getting into a continual feedback loop from customers/stakeholders to improve upon the feature set. Now, most business owners love the idea of “releasing as soon as one can” because it means pushing engineers as hard as possible.
However, there’s a clear difference between slave driving and getting something usable into the customers’ hands. Most business owners/companies end up not realizing that their management style leads to slave driving and a death march without the said SDLC controls in proper place. The death march, as I’ve talked about on multiple occasions on my blog, is what generally kills a team and product more than anything. The death march is a behavioral anti-pattern typically stemming from upper management’s view on a product. The product lacks proper SDLC controls, has no sense of scope, vague business requirements, an unrealistic tight deadline and no real justification for any of this. Personally, I wish the government made death marches illegal business practices for which people could blow the whistle on unethical business owners because at the end of the day, it serves no one.
The thing is that you do want a deadline but it has to match up with certain expectations that are set in the scope. The deadline will be defined in the iteration of what can be done rather than what should be done. The problem with deadlines is that it has the word “dead” in them (hence death march). Instead, the way a deadline should be looked at is an internal goal used for a milestone in delivering enough of a usable product for a customer so that you can start improving upon it via that customer’s feedback.
One of the best CTOs I’ve worked with was over at Demand Media and he talked about the idea of moving away from Date Driven Development to Feature Driven Development. This concept is just so critical because at the end of the day, dates really only matter for sales people and marketing for bragging rights. Dates really don’t define the usability of software and whether or not what is delivered is what the customer ultimately wants. I’ve seen too many failures or black eyes on products because marketing/sales demanded a date to be met at the sacrifice of the quality of a product. When this happens, you might as well just quit your job or watch the company erupt in flames and become a hated entity (examples are EA with Command and Conquer 4, EA in handling Origin Games’ Ultima 8/9)
Having an internal deadline though is good because of the psychologically in providing a limited framework in working towards a goal. You really don’t want to spend too much time on something and want to hear immediately whether that idea is useful or not. I think a huge problem is that the education system (at least in America) has cemented this idea of grades, tests and finals as being a system of punishments. With software development, the deadline becomes the equivalent of a test with a pass/fail outcome. While there is a parallel, the psychological implications is something you don’t want. The problem with the way the education system works is that we never see any reward for failure. Failure means we need a way to re-examine the errors that led to our misunderstanding so that we can in the future succeed (i.e. learning). Instead, classes and tests are seen as a finality just like deadlines. So with a deadline, most people end up equating it to their job and pay as opposed to building a better product through the lessons learned in the process.
As a result of this mentality, people are really afraid of failure and embarrassment. Some of the worst projects I’ve worked on were the result of an unwillingness to compromise and get the product into the hands of a customer for immediate feedback. Instead, the owners ended up holding on, fearing the negative feedback as opposed to listening in how the customer would want the product to behave.
The thing with a good feedback loop is that you need a constructive one in place. “It sucks,” “it doesn’t work,” or “XYZ is better” are not constructive. The feedback loop must include exactly what is broken, steps in reproducing the issue or what the customer wants in terms of the behavior. You need to get as close as possible to defining the expectations of a customer. Generally, you will want a combination of a community manager and QA (quality assurance) person to help assimilate this information and work with the product/project managers to figure out what can go into the next set of features.
Obviously, the customer cannot drive everything so you do need to find the correct balance between customer feedback, feasibility and your own vision of a product in coming up with a solid foundation. As you gather this information up, you will want to build a product roadmap. The product roadmap is a good resource because it basically offers milestones and gives people goals to work towards (not to mention something to look forward to). Instead of having all the features rolled up into a single release, you want to use the various requirements gathered and split them into scope/phases for each iteration that will be used as milestones in this roadmap. I would argue that marketing and sales out to plan around the roadmap rather than be the ones defining the timetables in a roadmap (they can still have a voice as stakeholders but not be the only ones controlling what goes in).
The last thing I want to talk about here is building a team. If it’s a one or two man show, then more than likely everything I’ve stated here is irrelevant. Yet if a company is growing, it’s important to build up a solid team capable of executing these steps. I’ve heard that a good formula is to have a UI/Designer, engineer and product/community manager at the very least. Some of these people on the team can take a cross functional role. For instance, the engineer can act as a product or even designer/front end developer while the product/community manager might also be a designer or someone who can help in user acceptance testing (which borders entering into quality assurance)
Either way, you need someone who has the vision of what the product is going to be and can articulate that vision to others. If the vision is large enough, then you might need multiple engineers on the project. Once you get 3-4+ engineers (can combine roles too like front end/back end), someone will need to take responsibility for managing the requirements, scope on an ongoing basis so that the work can be split between the engineers. Around the 8+ engineer mark, you might want to get a project manager. Also, I would advise that for every 3-4 engineers you have at least one quality assurance engineer.
I cannot underemphasize the importance of a quality assurance engineer as integral part of a team. While test automation engineers are nice, just having someone who has a solid understanding of the principals behind quality assurance is critical. A good QA engineer in my mind sees more than just the technical scheme of things but a larger picture. They can see the viewpoint of a customer and the business needs in determining what is important in developing test plans. You don’t want a QA engineer focused on trivial points (like the gradient of the background color unless it’s that noticeable). And you want to make sure that the QA person has the capability to communicate with various parties (including management) because they will help determine whether or not something gets released. More than anything the QA person will increase your confidence in your product. So get one if you don’t have one!
From an engineer’s point of view, I would argue that making sure you have overlap in skills is crucial. More often than not, one of the problems I’ve seen in a project is knowledge consolidation. Or in other words job security for some. But people can become a single point of failure in a project as well because either no one else is capable of handling that person’s aspect of a project or they develop something in secrecy. If that person leaves or gets sick, then the project can go into a downward spiral depending on how big of a chunk is required from that engineer. So having a backup or at least others who can pick up the slack will help in providing redundancy for that engineer.
Also, having code reviews should be part of the development culture, especially as the team grows. Code reviews should never be about destroying or defending the ego of one’s software skills. Instead, code reviews need to be productive sessions that help everyone understand the reasoning behind a coder’s decisions. They should go into the architecture/structural decisions and look to help the person improve code, looking for elements like style, inefficient code or questionable algorithms. Having code reviews in place along with other skilled engineers can help minimize the impact when someone takes an unexpected leave.
What about system administrators, DBAs, desktop support, etc.? In a large organization these roles help save time but for start ups they pretty much are useless. I think with the advent of the cloud, a lot of the value in having dedicated system administrators, DBAs, etc. are no longer necessary. Instead, I tend to value having solid engineers who can tune and setup the server software. What’s good about this is eliminating the usual bureaucracy involved with having an IT administrative side. Certainly, in organizations that require things like SOX compliance, you require them. But for building a good product, more than likely they’ll just get in the way.
At any rate, for most people this might seem like a very introductory piece on product management but it really is meant to target different people in an organization or business who want to get involved in software development to help guide them. There really isn’t a standard unfortunately but at least having a common knowledge on the minimal needs to build a product is really useful.