Brainrants
« “How To…” Get Customer Feedback and Input Quickly and Easily
Product Talks Review: Balancing Commercial Initiatives with User Experience »

Treat a Website like a Product

Tagged in: General
Treat a Website like a Product4.052

A product is a solution to a customer problem. Whilst this definition may seem simplistic, it applies for most products and services. A website is a tool that solves customer problems and can be defined as a product with a lifecycle and a roadmap.

What sort of problems?

From a customer perspective: A website solves a specific problem or requirement. These can be categorised as follows:

  • Learn: Share information about new products or services, announcements etc
  • Interact: Users can carry out functions via a website, such as online banking
  • Transact: The sale and purchase of other products or services, such as online grocery shopping
  • Share: Users can share information with others, such as posting up reviews about movies
  • Connect: Users can meet and connect with other individuals who share similar views and opinions

From the provider’s perspective: A website is a tool that facilitates interactions between the provider and customer, or between customers and other customers. Providers will seek a return, either financially or in some other form of value (e.g. information, feedback) from customers. A financial return can be direct (e.g. purchase) or indirect (e.g. online advertising on a site).

Applying the Product Delivery Development method when creating a website

The brainmates product delivery development can be used to illustrate how a website is a product by investigating the actions and outputs of each stage.

bm_model3

  • Idea: All websites commence with an idea – how will this site serve a customer requirement and how will it benefit the provider?
  • Product strategy: What is the overall goal of launching the site, how does it fit in with the other aspects of the provider’s strategy? What specific requirements do customers have and how will these be solved? A business case will be developed to green light the next stage.
  • Product planning: What does the market want? The problems and requirements and how these could be solved for the customer will be record in a Market Requirements Document.
  • Product definition: The stage in which the structure and practical elements of how the product will solve the market problems. What it will offer, what functions are required and what business processes are involved will be recorded in a Product, or Website Requirements Document.
  • Launch planning: Whilst design and development takes place, an implementation plan can be prepared. In the case of a website, this outlines the steps required to develop and bring content such as copy and images together.
  • Launch: Websites like any other product must be launched and this involves elements of marketing and communication to make existing and new customers aware of the site.
  • Day to day management: Reporting is a key component of managing a product on a day to day basis is also necessary when managing a website. If you treat a website like a product, you’ll not only report on the analytics but will consider the financial drivers. Importantly, the focus must continue as all sites have a product lifecycle and must be continually refined and updated to remain relevant and compelling for customers. This feeds back into the ongoing day-to-day product management of the site.

By regarding a website as a product, from its inception and development through to its ongoing management, you will make it more compelling and relevant to its audience.

VN:F [1.7.5_995]
Rating: 4.0/5 (2 votes cast)

Tags: , , , , ,

Posted by pgray , Thursday, November 12th, 2009 at 12:13 pm

4 Comments to “Treat a Website like a Product”

  • 1
    tim parsons
     says:
    November 16th, 2009 at 7:41 pm

    My : this isn’t a product development strategy – this is a product launch strategy, and a very simplistic one at that.

    What about testing ? You can come up with any number of business cases but without a real-world test, its all conjecture. You build and launch your taj-mahal product investing massively and … nobody wants it. How does this process avoid that ?

    What about agile development ? Rapid prototyping to prove a concept ? Market testing within a microsegment ?

    What about positioning of the product within a market or user-need ? This is absolutely vital for selling in the function and features of the product and has to be part of the product development cycle. Its called ‘b-r-a-n-d-i-n-g’. Google dyson dammit.

    All these documents – what are they for ? They’re for synchronising people. You don’t get any points for spelling or nice binding, its synchronisation that matters. Maybe there’s a better way ? Daily huddles ? Feature releases ? Screencasts ?

    What about product evolution ? The waterfall model really only applies in some (rather weird) circumstances. Just because nobody can think of something better doesn’t mean its any good.

    Its not a mechanical process, its a dynamic one. This needs to get a lot funkier before it moves past the ‘academic’ stages shown above.

    Phew I feel better already. Have a nice day !

    UN:F [1.7.5_995]
    Rating: 5.0/5 (2 votes cast)
  • 2
    nick coster
     says:
    November 16th, 2009 at 10:22 pm

    Wow Tim! That is the kind of comment that we like to see! It’s the kind of passionate comment that creates a conversation. Thanks.

    The first thing that I would like to clarify was that this post was created in response to a question that was proposed to us. How is a Website a product? Many companies treat their websites purely as “a channel” or as a “brand vehicle” and refuse to accept that a business website is actually part of the overall customer experience. We tried to describe how a website should be considered as part of an overall product experience and how we apply our Product Management focused methodology to achieve this.

    You have correctly pointed out that there is something missing fundamental to the product delivery process and that is the build, testing and release process where the product actually gets created. In fact I have updated the terms Product Development above and changed them to Product Delivery to help make this difference. At the point labelled “go/no go” on the diagram the Product Manager should be handing responsibility for the product development to the Development person or team. The Product Manager is still a stakeholder but the ownership of the activity is out of their hands. During the development phase all manner of development processes, like the ones that you have described, can be applied to deliver the best outcome that meet the Market Requirements.

    You have also mentioned unsubstantiated business cases and the benefit of testing to validate a product idea. The objective of the Idea Phase of the process above is to identify, size, test and validate the variety of Market Opportunities that may present themselves or be unearthed. While this step is often done based on gut feel and back of the napkin calculations we believe that it is an under developed part of the process that should be based on measurable data and research.

    It is a much better time to find out that an Idea has no legs than once the product has been built but just prior to a launch.

    Last point. You state that process is very simplistic. You are right. This stuff isn’t rocket science, yet we find far too often that companies rush off with a half-cocked idea that has no market validation, a vapourware business case and an ego driven development program. These products get launched and fail. By stepping logically through the high level product management phases we have found success with a surprising range of industries ranging from fashion to medical equipment.

    The process in words…

    [IDEA] Unearth an idea -> validate and size it with data -> [STRATEGY] Determine the business benefits and impacts -> [PLANNING] describe the market problem in detail -> [DESIGN] Design one or more solutions to the detailed problems description -> [LAUNCH PLANING] work out how you are going to communicate the new product to the market (+operational launch planning) -> [LAUNCH] Implement the launch and communications plan with the finished (and tested) product.

    At this level the process works just as well with a website which was the intended point of the post.
    Thanks again for your provocative words. It is great to hear from other Product Management People that care about this stuff!

    UN:F [1.7.5_995]
    Rating: 5.0/5 (1 vote cast)
  • 3
    Adrienne
     says:
    November 17th, 2009 at 9:49 am

    Thanks for generating discussion Tim.

    I agree with Nick. It was a mistake to call it Product Development.

    The work described above relates to the work a Product Manager does before it reaches the point of development.

    We’re not recommending waterfall or agile. In both the waterfall or agile method, requirements need to be gathered. Again – we’re not saying that as Product Managers we have to prepare Big Upfront Requirements but as a business we do need to understand what the customer wants and this ‘want’ or ‘need’ translates into some sort of document.

    We would be interested to hear what you would do differently before heading into development?

    UN:F [1.7.5_995]
    Rating: 3.0/5 (1 vote cast)
  • 4
    Matt Morris
     says:
    January 26th, 2010 at 5:19 am

    Finding customer specific requirements has long been a challenge. In fact, a survey of current automotive suppliers found that a significant number did not know where to go for the latest applicable customer specific requirements. For registrars and end users, this represents a serious problem. How can rules be followed and enforced if they are not readily available?

    It is with these challenges in mind customerspecifics.com was created. Here you will find a community to access, share, and discuss customer specific requirements.

    Please understand that the content of this site will take some time to develop as we work hand in hand with each of you to build a comprehensive database of the thousands of available customer specific requirements. We ask that you join us in our cause as we attempt to build something great for the common benefit of the quality community.

    UN:F [1.7.5_995]
    Rating: 0.0/5 (0 votes cast)

Leave a comment