Business Sense + Technical Sense = Common Sense

Common sense = ROI (Return on investment).

Getting the right balance between technological innovation and business acumen is critical for successful product development.

I worked for a company that designed and manufactured niche cutting edge products for the video and film industries. The company was principally engineering led, therefore there was always the temptation to spend a significant amount of time and resources producing products and or product features that would improve the quality of the pictures that were processed by the nth degree i.e. ‘Technical Sense’. The upside of this would be the production of products that would set or raise the standards and be a real break through in the market place.

The downside would be a real challenge for the sales team who would be given the task to sell high value, niche products into a market that may not appreciate or be able to justify (based on ROI) the extra cost for the increase in quality. A phrase I often heard at exhibitions and attending sales calls as I carried out product demos was: “your competitor has a product that’s good enough for the job and is at a very competitive price”.

On the other hand the sales team would frequently request features to be added to existing products or sell something prematurely so that deals could be secured. Good ‘Business Sense’.

The role of Product Management was introduced with the aim of achieving a balance between ‘Business Sense’ and ‘Technical Sense’.

I sometimes see history repeating itself in my current role as a Product Manager for a publishing company. I sit close to the engineers/developers and at the same time work close to the business (the commercial teams that have the task of monetizing our online products). I sometimes get requests for products and/or features that may take a significant amount of time to produce but may not achieve a good ROI in the desired timeframe.

As I mentioned in a previous article we are currently implementing an agile development framework know as Scrum. Scrum aims to bring the business teams close to the development team. Bringing a level of transparency and enabling both the business and the technology teams to get a ‘hands-on-understanding’ of each others issues. Or put another way Scrum aims to make:
Business Sense + Technical Sense = a large ROI surely this is just plain Common Sense.

Has anyone experienced a noticeable increase in ROI as a result of
implementing Scrum?


  1. Cooper, the interaction/product design firm founded by Alan Cooper, likes to talk about this same idea as a balance of three forces:

    - Marketing: the product must be sellable and distributable
    - Engineering: the product must be possible and feasible
    - Design: the product must be useful and desirable

    (Source: Putting people together to create new products)

    They have a diagram that shows three overlapping circles with "Product Success" in the center.

    I like that concept because it promotes the idea of those forces being in balance. There are plenty of examples of well-designed and well-engineered products which were not marketed well, or products with great marketing and technical robustness but poor design.

    Good products are ones with enough "technical sense" that are designed to meet the needs of the customers/users and have a solid marketing/sales plan. Sounds like common sense but often is much more challenging ;-)

    Blog: How To Be A Good Product Manager

  2. Hi Derek,

    You said that you were trying to implement SCRUM. Which tools will you be using?

    If I may suggest (and I am biased in this regard because I am involved with the project myself) check out Yoxel Systems It is a tool for product managers and can allow your teams to do SCRUM, yet it is not enforcing any particular methodology/terminology (and could connect to your existing bug-trackers).

    BTW, feel free to write to me directly: alexey at

    In some companies the transtion to SCRUM is not that simple. Management likes to use traditinal terminology and approaches (GANTT charts, resource allocation, ownership) which is not always bad.
    So in my opinion you often come up with a hybrid agile apporach (kind of SCRUM + traditional + your home grown methodos).

    In a company where I work we at least managed to switch to 1month incremental releases (2weeks implementation, 2weeks testing) and SCRUM-like backlog management which is a big improvement to the process. After 3-4 iterations we see how many requests our R&D can handle in an iteration and we can learn, react to changing market requirements faster and plan next iteration better.

    So I would definitely recommend SCRUM as an idea for your agile process but would not worry too much about the terminology that comes with it. Just do shorter incremental releases (some organizations choose to do 2weeks) and encourage more collaboration within and between R&D,PM,marketing, ....

    BTW, is there an RSS/mailing-list for the blog I could subscribe to?

    Here is a good blog with tons of useful information for PMs:

  3. Hi Alexey,

    At present we are using Excel and sketching tasks/storeies on white boards. I should be starting my first Scrum (proper) in a few weeks time may of the PMs I work with are currently using it.

    We have around 12 and when we finsih recruiting 14 PMs most of whom will play th erole of Scrum Master - so th eidea is to get all teams running in the same way - so that we developers, testers and PMsnare able to cover for one another.

    The Dev manager and technical team leaders are reviewing Microfts Team System and a plug in from Conchango -
    Scrum for Team Systems

    I need to check the RSS out - will get back to you.