Agile software development in a startup is fast, challenging, exciting and dynamic however one of the hardest things to accomplish in this environment are  predictability and repeatability.  When teams start agile development the first sprint(s) can often be disastrous, and lead to abandonment.  The easiest way to build predictability into the process is to think about a Agile development as a simple supply (engineering resources) and demand (product needs) relationship.  The key is to increase the accuracy on both sides of the equation.  

When you read literature on Agile development there are a couple of standard techniques suggested to improve predictability:

• Triangulation:  The process of tracking estimates and then when a ‘like’ feature comes up you use previous estimates to triangulate in on a reasonable estimate. 
• Cycle Velocity: Teams track velocity or points throughput over a given (short) development cycle, and uses this as a starting point for the next cycle.

Great!  except that in practice these are marginally effective at first.  One of the things we have found to be a great step forward on the demand-side estimates was to create better definition around the base estimation factor.  Estimation, and product throughput in agile development is typically measured in ‘points’. There are different schools of though on how a point is defined. Through time and experience we have found the following definition works best for us:  A point is one day’s worth of development time with little to no interruptions by a senior software developer.

With a more defined based estimation factor we then added complexity multipliers to our user stories (feature requests) to help with triangulation.  Often we would get bogged down in a lot of what if discussion which is good, but often created angst among the developers when trying to create estimates. We moved to a model where estimates were stated as best-case, and then we would add multipliers for both technical complexity and business complexity to generate a risk adjusted estimate in addition to the best case.

Now what about the supply-side?  Often overlooked, but just as important…If not analyzed correctly it can create an overworked engineering team.  Of course in a startup, everyone is overworked, but the key is sustainability. Especially with small teams and short development cycles small supply-side ‘events’ can wreak havoc on predictable product throughput. We have found that the following items need to be effectively factored into the supply-side calculation:

• Team member skill levels
• Vacation time
• Overhead/support needs

Every team member starts out with a baseline FTE (full time equivalent) value of 1.  First we start by adjusting the baseline value down to adjust for skill differences in junior resources. Any vacation days that the engineer will be taking during the sprint cycle are then factored in, as well as the expected % overhead (P1 bugs, production support)  that each resource will be expected to cover during the cycle. Calculated out for each resource and then added the numbers together gives you a net FTE count for the team, which can then be multiplied against the days in the sprint to give you a baseline supply estimate.

During sprint planning we then begin estimating against the demand until you hit a number where the supply-side estimate is approximately sitting between the demand-side best case estimate and the risk adjusted estimate (assuming some stories will work out closer to best case and some will work out closer to worst case). 

These minor enhancements along with team experience have allowed us to create an extremely predicable product development process, that is not only repeatable but also sustainable.  All critical in startup product management and software development.

If this concept interests you - let me known and I can send you the spreadsheet template.

On the heels of our recent successful on-time launch of the next version of our Local Marketing Automation platform, I though I would go back and revisit what we have accomplished over the past few months and some of what lead up to this initiative.

From a macro perspective, it might actually be considered almost textbook SaaS (Software as a Service)development: Build and prototype quickly, get customers early, get feedback, drive to early revenue, continue iterating the product features and re-architect the technology in a just-in-time fashion.  Then, of course add in your typical startup constraints - budget limitations, resource constraints, just to spice things up!

Let me first take you back to the dog days of summer in August 08 when we launch what might now be called the beta release of our Local Marketing Automation platform (although we resisted the convention of actually calling it a beta) with our first set of customers.  The application showed immediate value, and our user base grew quickly.  However, by December of 2008, it became obvious that from an operational and scale perspective we had a few issues that might get worse given our current trajectory.  Additionally, aggregated customer support call data indicated a number of recurring themes, in addition to feedback from the field with potential clients showing some leading indicators of potential cracks that might become problematic when our growth track continued.  All of these diverse data points were indicating a need for a larger revolutionary overhaul over the current evolutionary development model.

January 2009: In addition to our standard ongoing iterative development process, we began brainstorming ideas for how the application could be redesigned to make a revolutionary leap forward.  We did this with a user-centric approach, starting at the user interface and worked backwards into more of the technical aspects of the design.  Even though our product falls under the B2B application space, our focus was to designing it for a B2C user from a design and usability perspective.  We wanted to make the application intuitive and usable, without the need for extensive training.  We first looked at other sites that were popular on the web that had related functions and worked well in the consumer world.  We then took these design concepts, mixed them with our domain expertise and applied them to our product.  This first produced a few hand drawn mocks, followed with some more functional screen flows put together in PowerPoint.

Next, we shopped these around to our all teams internally - sales, marketing with a deep focused on the groups that interacted with the app and our customers directly (inside sales, account mgmt, support).  They were our best window to our customers without the time or luxury for extensive market research.  Along with this, we presented the conceptual flows to our current client base.  From here, we moved forward by presenting the concepts to a select set of actual end-user customers identified by our account management team.  Looking back at my files there were at least a dozen major revisions through these prototyping exercises with many many more minor tweaks.

Now that we had a good idea of where we were going, the next step was to engage our creative team, who then gave the life to our wire-frames as they would appear in the real application.  This also served as an exercise in breaking down our interface into named visual components to support a common language when talking with our technical team.  This turned out to be a critical factor in ensuring we could develop the solution at breakneck speed.

So, to give some perspective - we did all of the above over a 2.5 month timeframe through Mid-March as a side project, while we still continuing to do iterative development to enhance the existing product (being extremely careful not to develop things that would likely be thrown away with the upcoming redesign).

In March we started working with our technical team on design to see what the new concepts would mean to the underlying architecture (data and business logic).  It indicated large changes - but for the better.  We would be able to throw out a lot of things and build new structures that would support our customers more effectively.  (In the end 80+% of our data structure and code base would be rebuilt).

In April we started the first of two formal development sprints with stabilization periods between each that would span a total of approximately 12 weeks.  In that periods of time, the product and development teams (with the support of the rest of the company) carried out a Herculean effort of rapid design and development - making constant adjustments as new issues arose.

About 4 weeks into the effort we locked down our release date to June 15.  This was critical to support ongoing sales efforts and work with clients to support their internal planning.  Due to the large number of dependencies and the scope of the change, about 6 weeks in, we had to start managing the overall effort with more of a ‘traditional software project management’ technique to incorporate all of the other pieces required for a release of this magnitude (customer transition & training efforts, outbound communication, cross company testing etc.)  However, at the core we continued to follow agile development principals, and the agile mind-set.

The cut-over was planned on a weekend, to give us the most time to react to any issues with the deployment.  We used almost all of the hours in that weekend to upgrade, convert customer data and validate to ensure a successful go-live on Monday morning.  On Monday June 15 the latest release of our Local Marketing Automation platform went live! … breath.

In retrospect, here is what I would consider to be our 5 key success factors for this redesign:

• Relentless focus on the customer, and letting form drive function
• Domain knowledge backed up with real world experience from the beta allowing us to design/build rapidly and make fast decisions
• Fanatical focus on prioritization to time-box the effort
• A passionate product and engineering team with a ‘lets getr done’ attitude
• An all hands on deck mentality across the company to support the product release where and when needed

Within days of launch, feedback has started rolling in from the our support team and through our customer transition/training webinars being held.  Here is a quote our support team received on day 2:

“I just wanted to say thank you for what you’ve done with the tool.  I had a list of things that I wanted to see changed, and this new version has covered almost all of them.  I really appreciate the changes you’ve made.  It is a lot more user friendly.”

Of course you can never sit on your laurels for very long as constant improvement is a must to stay competitive, but at the end of the day this is really what product development is all about. A satisfied, excited customer.

We are excited to announce that we have recently joined forces with Carpet One Floor & Home and are currently working with their fantastic retailers as they employ Balihoo’s Marketer Edition. As their new media partner, Balihoo will enable their 900+ retailers throughout North America to lower overall marketing costs while implementing distributed demand-generation efforts effectively.

The Balihoo Marketer Edition portal we have created for Carpet One Home & Floor, MarketRIGHT 3.0, benefits Carpet One retailers in numerous ways:

- Provides the ability to easily access and customize corporate creative templates across all media forms (print, radio, television, online, search engine advertising, etc.)

- Tracks comprehensive web-based reports to accurately track their marketing efforts

- Guides the planning, negotiation, purchase and the local placement of each store’s media

And the list goes on. 

Wayne Wengerd, owner of Bear Carpet One Floor & Home in Sugarcreek, Ohio commented, “I have been pleasantly surprised at what Balihoo can do. It’s very thorough and well thought out. Balihoo makes it easy to create, manage and execute our advertising campaigns across the complicated media landscape of print, online, radio and television.” Wengerd went on to say, ”It’s a win-win for us: we are able to identify the best media mix - at the best price - to target potential customers.”

Carpet One Floor & Home is the largest division of CCA Global Partners and an ideal group of people to launch our Marketer Edition with. 

 To read more about our relationship with Carpet One please click here.

In Product Management, the Product Roadmap is often thought of as the centerpiece to this function, however in practice roadmaps can hinder or mislead the organization more than they help depending on how they are used. With software, product road maps become even more difficult to manage and maintain, especially as you move into agile development methodologies. The very thing that makes agile effective, works against a typical product road maps (if there is such a thing). Furthermore, couple this with a market such as advertising, that is undergoing drastic changes, and creating a product road map becomes a challenging exercise.

Software product road maps are typically linear presented on some type of calendar view read from left to right. They often resemble a project plan in Gantt chart view, and there is little distinction between a product roadmap and a technical release plan. However just like with project plans, the further out you plan, the more the plan breaks down and becomes vague and unusable. The problem is that project plans, and roadmaps organized like project plans give the illusion that it is humanly possible to plan out a year or two in advance. In my experience, even with seasoned project managers, and a solid vision, project plans begin to break down as early as 4-6 weeks from the date they are built or revised. Second, product roadmaps have a completely different audience, and objective than a release plan does.

So, what is a product manager to do? Sales and marketing still need to be able to talk about what’s coming to the market, prospective clients, as well as current clients. Engineering needs to understand the vision for the product so they can create an architecture that will support future growth, and the company as a whole needs to understand where the product is going so they can get behind it and help create ideas to make it better.

In thinking through the goals for an effective software product roadmap for Balihoo, I came to the following needs:

• ensure the product features support strategic objectives of the company
• indicate relative importance of features (revenue potential, market appetite)
• an approximation to timing
• indication of how ‘robust’ the feature should/will be

So how did it turn out? I took a visual approach that resembled planets orbiting around the sun. The sun in this case represents the strategic objectives of the company, and the orbits and the planets represent high level features that are currently being planned for the product. Distance from the strategy sun indicate timing, and with that relative importance as well. Coloring of the feature indicates how robust or ‘enterprise class’ the feature needs to be based on current market expectations/needs.

In addition to being a great visual representation of the product for inside and outside the company, I think it also presents a more realistic picture of a product in a changing landscape. In addition, as the strategic objectives of a company change it becomes easy to shift the features up or down to represent the changes. It may not have all the details that a traditional product roadmap has, but it isn’t meant to, and furthermore that detail belongs in a release plan, not in a product roadmap.

Products in a dynamic market cannot be mapped out like a project plan. They need to be continually monitored adjusted with a shifting market. The product roadmap needs to be able to shift easily with changing needs, and yet still present a view of the product that stakeholders can understand, convey to others, and provide feedback on to ensure that the product will continue to provide optimum value to the customer.

In addition as with any new idea, this product roadmap design will also continue to evolve and meet the changing needs of the business.  Thoughts are welcome.

Balihoo is continually dedicated to streamlining the manner in which the media planning process is carried out. For both parties involved in the process (buyers and sellers) there seems to be an ever-escalating need for heightened efficiency in the RFP/RFI (Request for Proposal/Request for Information) process. The Balihoo Worksheet is one component of our system that seamlessly and effectively conducts and manages RFP’s and RFI’s for you. Resulting in accurate, rapid and customizable data (which undoubtedly results in fewer migraines for you) the Worksheets are equally valuable to both the buyer and the seller.

 From the Seller’s Perspective - Balihoo’s Worksheets 

The Worksheet jumps into action when you receive a RFP.

The Worksheet offers you an efficient, online and centralized location where you can respond to the RFP’s you receive from Balihoo. The responses that you enter will automatically flow into the buyer’s Worksheet, thus ensuring that the number exchanging process goes flawlessly.

In addition, the Worksheet allows you to save responses. By offering a tool that allows you to quickly respond with “standard” responses you are able to focus your attention on what’s really important:  the strategic components of the RFP process.

From the Buyer’s Perspective - Balihoo’s Worksheets

The Worksheet jumps into action when you begin to receive responses to your customizable Request for Proposals (RFP).

When you issue a RFP the responses to that RFP automatically flow into an online worksheet. The great thing about our worksheet is that it is completely customizable and was built on the premise of simplifying the comparison process.  With the Balihoo Worksheet you no longer have to tediously copy/paste section after section in an attempt to compare responses; the system filters and files your customized RFP responses automatically into an easy-to-use spreadsheet. The Excel-compatible worksheet allows you to easily identify and compare the information that you need, thus allowing you to spend more of your valuable time focusing on the strategic components of the RFP process.

Just another reason why Balihoo truly is the media planning professional’s best friend.

In building out our Agency Edition of the Balihoo tool, one of the things that we realized in talking with our customers is that vertical organizational structures are often less important than client or account based structures. As service based companies evolve, your physical office is purely where you live, while creating ‘walled gardens‘ around client data is much more critical. Agencies are no exception. From our lens on the media buying world, a walled garden is one where certain data that needs to be protected inside the walls, but aspect of this data can be shared across the enterprise to make the organization more efficient as a whole. For example, negotiated rates and media mix for a client may need to be kept protected, however the buyers interaction with vehicle owners or contacts should be available to ensure efficient RFP response and campaign development for all clients.

To facilitate this, Balihoo has developed a feature called Agency Access Groups, which allows walls to be put up around client data, to the level at which is required by their client. These walls can be set up at the account level, brand level or campaign level depending on the needs of the client as well as the competitive nature between clients in the same industry.

This tool allows the creation of data walls within a given office or across multiple offices within the same buyer company depending the the needs of the client. Agency Access Groups are completely managed by the buyer administrator through our admin console, and can be changed or updated as needed when new clients come on board or new groups need to be defined for different business applications. This will give the agency the flexibility it needs to streamline their business while offering enhanced service levels to their clients. Contact Balihoo for more information on this feature and how it could be used within your organization.

The Center for Media Research posted an interesting research brief today on the recall performance of green messaging.  According to the article, a recent study found that “37.1% of consumers [say] they frequently recall green messaging and an additional third [recall] it occasionally”.  These very high recall numbers would suggest it’s time for celebration in many a marketing department.  But let’s keep the cork in the champagne bottle because the real learning here comes from the stat that “22.7% [of] respondents say they seldom or never believe green claims made in advertisements”.  In essence consumers are saying, “Great job on getting me to remember your message, but I just don’t believe what you’re telling me.” 

Part of this problem may be attributable to the fact that when it comes to defining “green” there are several ways to skin a soybean.  Today’s Marketing Daily article on the FTC’s upcoming regulatory review of green packaging makes the point that as consumers face an overwhelming set of new environmental terminology confusion abounds.  When purchasing products across (or sometimes even among) brands consumers can’t easily translate packaging claims into real-life attributes, so marketers must be the translators.  And that translation better be relevant, valid, and intelligible. 

Yes, we should strive for message recall, but if that message lacks credibility or clarity then silence would be better.  Marketers who communicate clearly, educate consumers on the environmental lexicon, and openly substantiate their claims will do well in the green revolution.  But this is a lesson to be broadly applied to the marketplace at large; it really boils down to helping consumers find solutions to their problems, whatever the color.

If you are a media buyer, Microsoft Excel is probably one of the most used tool in a your quiver. However, even with Excel, the pain that media buyers face when putting together a plan is still substantial - getting the data into the tool from dozens of emails, different spreadsheets, all with a slightly different format, and transcribing data from handwritten notes. Balihoo now offers you integrated media planning worksheets. This web based worksheet feature offers you all the functionality you require from a standard spreadsheet, as well as automated data integration features to eliminate wasted time manually transferring data into a spreadsheets to start the ‘real work’. In addition, it gives you a central repository of historical worksheets all tied to a campaign, brand or account so you don’t ever need to worry about finding historical data for reference.

Balihoo worksheets are tied directly to your campaign, so all members of the campaign team will have access to the most recent version of the worksheet. There are no limits to the number of worksheets that can be added to a given campaign. You can copy an existing worksheet to set up different buying scenarios, all based on media properties that you have added to your consideration set through the Balihoo tool. You can even build a new worksheet off of a design from another campaign, without having to start from scratch. Just like other spreadsheet software, you can add your own columns into the worksheet, you can created calculated fields, format fields for different number types (percent, dollar etc), and sort the columns in any way you want. In addition to columns, you have the power to add as many sub-rows per media property as you deem necessary for analysis. For example if you want to split different creative unit out as different rows on a given media property, you have the ability to do so.

Although the above features are important, the real power of Balihoo worksheets comes from its data integration features. First, all media properties in your consideration set are automatically available to you with any attribute houses in the Balihoo system. Media properties can automatically be filtered or excluded based on the status of each. You can look at all properties in the consideration set, or only those that have already been selected for plan, or even those that were previously removed. This list can automatically be refreshed to get any current updates from media property owners OR kept static to keep a snapshot in time. Second, and more importantly, any RFP that has been sent out through the Balihoo application is immediately accessible for your campaign worksheets. No longer will you need to cut and paste from emails sent back to you from property owners. Once they respond to your RFP, this data will be immediately available in your worksheet for analysis. And, to make things even better, as responses trickle in from publishers, each time your worksheet opens, you will see the latest responses already loaded for you.

Lastly, Balihoo realizes that ultimately you will need to extract the data out to an external package for final formatting, graphing, etc. To facilitate this we offer complete export features on the data. Once your plan has been built, you now have a system of record to house the data, but also have the power to extract and format for presentation to a client.

Balihoo worksheets is now live in production for Pro and Enterprise customers. Look for continued enhancements to this tool in coming releases to make an even more powerful online data integration ,analysis and collaboration tool.

As 2007 begins to wind down, the Balihoo product team continues to move forward with new features and tools to make media buying and planning more efficient!

Continued development of Buyer Search and Discovery Tools

• Many products such as TV stations use counties to define their coverage area, so Balihoo has added counties to help better define product coverage. Now coverage can be defined at virtually any level including State, DMA, County, City, or Zip. This helps owners better articulate their coverage area and also enhances a buyer’s ability to find the coverage area they need for their campaign.
• Advanced Demographic Profiling is now available! Within each demographic category (e.g. Age), correlations can be set for each subgroup within that category instead of just selecting the best subgroup for that category. This helps owners give a full picture of their product demographic coverages and helps buyers search and find better products to meet the demographic needs of their campaign.

Buyer Campaign Management: Balihoo is beginning to make the media campaign the centerpiece of the application experience. This started with some enhancements this past month that include:

• Campaign Console which becomes the central hub of activity to manage all aspects of a media buying campaign
• Enhanced features for pruning and manage your consideration set
• Campaign document management to keep all your key documents and deliverables in one place
• Notes management, which allows you to start conversation threads on the campaign itself or even about individual products within the campaign.

And all of this is walled off to just the users within your organization!

Owner Product Promotions: In addition to our free media property listing service, there are new features that allow publishers to enhance their product listings, which will help drive traffic to a possible sale. Balihoo is also offering an analytics feature that allows publishers to get an idea of traffic on their products within the Balihoo application.

As fall sets in, I thought it was time for another product update. While many enjoyed vacation over the summer, we have been extremely busy on new features including a new module to facilitate the media buying RFP (Request for Proposal) process. RFP’s in the media world are a little different than the standard, often strict RFP processes. We have built this feature set to be flexible enough to support the unique needs of both media buyers and owners in this often crucial phase of a media buy.

For Media Buyers

• Jumpstart your RFP - After using the Balihoo search engine to build your consideration set for a given campaign, you can then initiate an RFP from within your campaign that will allow you to select products out of your consideration set. It will also pull over basic campaign details for you so you don’t have to re-type them.
• Re-use with RFP’s - How different are your RFP’s within a given medium? How can you delegate RFP work without sacrificing quality? The Balihoo RFP module allows you to pre-define reusable specs (questions & directives) that can be re-used across different campaigns. You can also collect a set of specs into different templates (say by medium). Whats more, Balihoo comes pre-loaded with a full set of standard specs and templates.
• RFP Design Flexibility - Have you ever used survey creation tools? The Balihoo RFP builder gives you equivalent flexibility to create RFP questions in many different formats. Text responses, single selection lists, multi-selection lists and more. You decide the question and how you want owners to respond.
• Getting your RFP to the right person - Whether you want to use a company contact for a given media property or want to select from the contact list within Balihoo, you have the option, and if you don’t know who to send it to, we will send it to the default contact defined for the media property.
• Handling Updates - Balihoo understands that RFP’s need to be modified after the first release, and will help buyers and owners manage these changes. New properties can be added on the fly without starting the process over again and impacting current responders. Changes that will impact an owners response (adding an additional question), will be communicated through the application to ensure that responses are consistent.
• Managing responses - The Balihoo RFP module will allow buyers to look at individual responses or compare responses to questions across multiple responders, to make the best decision for the campaign buy.

For Media Owners

• Receiving & Responding to RFP’s - Media owners will be proactively contacted via email when a new RFP is received or is updated by a media buyer. All RFP’s coming in from different buyers can be managed in a single location. Balihoo will keep track of all current and past RFP responses for future reference.
• Handling Updates - The Balihoo RFP module will help owners determine what has changed in an updated RFP and if it will impact their response. When questions are changed all existing responses will be carried over to the new version where applicable.
• Adding Additional Information on a Response - Owners can upload additional collateral to support any response to an RFP request. In addition owners can add ancillary comments to any question that has a defined response.

This is just our first release on this module. Stay tuned for more to come!