A Business Technology Place

Give it a go

Disclaimer: I am a Google Adsense user on my blog, but I do not pay for Google ad placements on search results.

Several years ago I received an offer from Google for $100 worth of free ad placements. It was the start of a grand adventure at work. We ended up using the $100 credit to purchases ads for the eCommerce site at work and then multiplied the value of the credit. As you would imagine that led to more ad purchases (paid this time) and quite a bit of fun exploring different ad placement,.  bidding, and keyword techniques.

This last week, I received a very similar offer from Google. They are offering $100 if I spend $25. It’s for new customers only. I am classified as a new user because I’ve not used paid ad placements with my personal account or blog. It’s tempting to play with the credit for fun, but the purpose of my blog isn’t eCommerce sales.

I like the concept. I remember telling my manager that configuring the bidding and pricing of Google adwords felt like gambling. The great thing was it was easier to turn the odds in our favor and no one became suspicious if we left the day with more money than when we started.

So with all that said, I do experiment with adsense ad placements on my blog. Maybe I should give it a go.

Onward and upward!

B2B eCommerce – It’s different

Some thoughts about B2B eCommerce.

B2B eCommerce has been part of my life since 1999 when I worked for the John Harland Company. At that time, I was on a team creating and deploying an internet site for bank employees to order checks for their customers. In the last fifteen years I have worked with both B2B and B2C sites and I can say that B2B sites are different. Business approach B2B differently. B2B development efforts focus on different aspects of eCommerce.

Much of B2B eCommerce focus is on functionality and features. The development teams often focus on the business workflows within the customer’s business as a way to add value. As a result, there is less focus on customer experience created by UI designs than a B2C site. There is less focus on metrics like conversion and bounce rates. When I product managed a B2B site I liked to ask, “how can we create a flow that reduces speed bumps and just enables the customer to complete the transaction they signed-on to complete?” In other words, let’s not trip the customer and just let them create a transaction. B2C sites like to create diversions in hopes that customers will add more items to the cart before completing check-out.

Andy Hoar of Forrester recently blogged that US B2B eCommerce is forecasted to reach $1.1 trillion dollars by 2020.  This is not surprising, because technology continues advance to put capabilities in the hands of those that purchase for businesses.

Hoar cites a couple of contributing reasons:

  1. Today 70% of B2B purchases are researched online but only 30% are purchased online. Forrester predicts that gap will shrink.
  2. The economics of electronic order fulfillment are better than manual orders. Businesses know that electronic orders reduce costs in order entry labor, phone support, and supplies. Not to mention electronic orders typically create faster fulfillment times for the customer. When I worked for Harland we called this idea “Channel Shift”. There was a metric each year to incrementally reduce manual orders by increasing electronic orders. We even knew the dollar amount of cost take-out associated with shifting 1% of orders to our eCommerce channels.

But wait. Other factors are at play that influence the number of B2B eCommerce orders.

As I think through my experience and challenges my teams have encountered with “channel shift” a couple of things jump out:

1. Custom orders – eCommerce sites are easier when the product set for a customer is SKU driven from a catalog. The workflow changes when customers are allowed to customize a product. As the number of customizable features grows so does the level of complexity.

But more than the technology challenge with custom products is the education and knowledge challenge with the product set.  Buyers on B2B eCommerce sites are not necessarily experts on the products they are purchasing. They rely on the research and the company representatives for this expertise.

2. Relationships – Much of the B2B commerce marketplace is built on relationships. A successful salesperson will add value to a relationship by bringing product expertise to the discussion with the customer. The successful salesperson will show the customer how the product can be used within the customer’s business to drive value.

Believe me, I want to enable and influence channel shift. But this is more than a technology puzzle. There are businesses processes, product attributes, and people relationships that are part of the equation. I haven’t found a set magic formula or one-size-fits all approach. What is clear is that businesses and customers are looking for ways to use technology to make their processes more efficient. With both sides looking for a solution, success is there for the taking.

Onward and upward!

The speed of software releases

How fast do you want software released?

I was part of a discussion this week week about the velocity of production software deployments. I didn’t use velocity in the context of estimating software but rather the benefits of a regular cadence to releases and the focus it brings to the testing effort. The velocity of the team affects the frequency of production changes and thus in a sense affects the overall risk to the organization for disruption to existing services.  If we release software too quickly, I believe we increase the risk of service disruption and create inefficiencies in system-level testing. If we release software too slowly then we increase the risk of losing competitively in the marketplace as well as losing customers.

Boris from GoldenEye knew what he liked.

Boris from GoldenEye knew what he liked.

This wasn’t a discussion about agile software development principles.

For my part, I was curious about the relationship of production software releases,production defects created by those releases, and the testing effort required for approval. Maybe velocity was the wrong term to use based on its agile methodology definition.  My focus was on the frequency of change events to the production environment. In the most basic form, software releases can arranged by individual unit (feature/bug).  Each time there is a production release it requires at a minimum unit testing for the bug or feature that is new or has changed. But when we don’t do some level of full system testing we may miss items that are broken as result of the code change. All production releases by nature have some element of risk to disrupt current services.

What’s the right software release frequency?

Obviously the answer to this question depends on a variety of factors. Software and business teams make choices and decision about how they answer the question.  I look for a balance to provide support in the following areas:

  • Quality Assurance – The testing effort should have time  focus on feature and system-level testing.  Full system testing should reduce the risk of introducing new bugs into production as result of the new code.
  • Maintenance window – Excluding full system outages, the maintenance windows provide an agreed-to time for production updates. So if the maintenance windows are every other week then the software release schedule should not exceed every other week.
  • Priority – Not all production defects require immediate resolution.  The balance is to fix priority defects in a timely manner but not so frequently that it increases the risk and pressure associated with quality assurance thoroughness.

Remember what it is all about.

The point of velocity is not to tick a check-list that we have a process. The velocity does have benefits with estimating. But the real value is to provide a regular cadence of features with the highest quality to the customer. Most of all, the customer should understand the flow and be part of the process.

Onward and upward.

Software open feedback loops

What is the secret sauce?

What really drives new software features? Do we live in a world where the marketing department rules the day with ROI driven and profit making capabilities from within the software? To an extent, I believe the answer is yes. Businesses exist to make money. Business software is written to facilitate the flow of money either through sales or automation of processes. If a piece of software doesn’t help the organization to make money it won’t last long.Simple_Feedback_02

But software that is not used, doesn’t make money. No matter how good the idea, if the software is not used, the business justification fails. This is why an open feedback loop with users is critical to the success of the software and could be tagged as the secret sauce for software development. User input drives usage. Usage accomplishes the goal for sales or productivity.

Creating the WOW.

Service organizations like to create the wow factor with customers to drive brand loyalty. Good software has that effect also. I see people that are passionate about Evernote, OneNote, and Photoshop as examples. Evernote survives with paid subscriptions. With a free-version available, and many options for recording/capturing notes, they have to “wow” customers to keep the software in the market place. The Evernote blog is a good place to see user input and feedback. Users provide feedback in the comments section and are often cited in case-study like blog posts. New features sometimes don’t have a direct link to increased sales. But they do have a direct link to usage which has a direct link to sales.

I was pleased this week when I heard a product manager tell a steering committee that we have a good feedback loop in place with the user-base that is driving feature enhancements in a software tool. Some of the feature-adds were completely cosmetic. But they were added to drive additional usage on the site. For the site referenced by the comment, additional usage means increased cost reduction through productivity gains in the back-office. If we execute properly, we should position ourselves to deliver the wow factor for the users. That was exactly the point of the comment.

So I submit that the open feedback loop with customers is the secret sauce that helps software achieve it’s stated goals. Product managers and marketers have to find the balance between user input and needed features for ROI. Without usage, the software is just a heap of 1s and 0s.

Repeating software processes. To attract and repel.

Are we attracted to repetition?

Yes.  We all are. It touches every facet of our lives. As a few examples, we eat the same types of foods each week, we watch the same TV series, and we read books that belong to a series. A study and report from Alix Spiegel of NPR captures the power of repetition in music that attracts us. Spiegel reports that “90 percent of the music we listen to is music we’ve heard before. We return again and again to our favorite songs, listening over and over to the same musical riffs, which themselves repeat over and over inside the music..” She then gives the result of a study that shows how people preferred music with repetition over the same song without repetition.

Repetition in Software Development.

Software development has the same draw for repetition. Managers spend time and thought to create a software development lifecycle (SDLC) that fits their company culture and team skill sets. They want something repeatable to drive efficiencies of a process, consistency of work output, and reliability of estimates. These are the attractiven features of a SDLC.

There’s an entire business industry built on repetition in software development. Books, training, and consultants feed us new ideas and different ways to think. But the end game they seek is adoption to a standard method that works within the framework of our business culture. This is all for good reason. As a professional in the world of software development, I recognize that we must be disciplined. I recognize that we have to think and find more efficient ways to produce software so that we can stay competitive and drive results through the business.

But there is a repelling force to repetition as well.

There are two danger zones that software managers should consider with repetition in process. Both of these creep-in an organization silently. Ironically they destroy the very things that repetitive process can build.

  1. Repetition can stagnate creativity. When we follow a script, we don’t think much about the ‘why’. We don’t think about better ways to do things. We just follow the process because someone already did all that thinking. Worst of all is that we don’t see it. We think we are accomplishing our job because we followed the steps.
  2. Repetition can become the end goal. When checking the boxes on the process flow becomes more important than the final product then the process has become the master. If employees are consumed with following every detail of a process and only satisfied when they mark steps as complete then the process has become larger than the importance of the end result. You’ll recognize this in an organization when the meetings about the process outnumber the meetings about the solution, the who, and the why.

Watch for it!

Watch for it in your organization and life. It’s like two magnets with forces that attract and repel. We have to find a way to both pursue and guard against the powers of repetition in the workplace. This means constant examination. It means living with shades of gray within process. It means we need write with a pencil, allowing for a both a sharp and dull point. The eraser is nice to have also.  🙂