Showing posts with label Development. Show all posts
Showing posts with label Development. Show all posts

Act! Certified Expert – Sanctioned by Swiftpage #ActCRM

Act! Certified Expert - Santioned by Swiftpage #ActCRMOver the years, Mike Lazarus has been the recipient of many unique awards and certifications related to his work in Act!, including:

In another first, Mike has just been sanctioned by Swiftpage as an
Act! Certified Expert

As indicated in this previous blog post, Working with Act! Again, Mike has been working with Swiftpage for some months to identify and resolve outstanding issues and to improve the stability and functionality of the product. Now he is connected with the QA and Development teams in testing some of the enhanced and new features expected in 2018 before they go to beta and then release.

Some important ones regarding Office integration have been announced in this December 2017 Letter from Swiftpage’s President, Lorcan Malone to registered Act! users.

Please respond in the comments with any areas or bugs you think need additional testing.

How Are Product Management Decisions Made?

Part 2 of The Seven Day Blogging Challenge - Answer one question I think people visiting my blog may have.

Recently I have been trying to explain to users in a couple of forums why the feature they want might not be likely to make it into the product. For a couple of examples of this, see:

So I thought I might try and explain simply how I see the product management decision process. However, please note that I’m not actually privy to the process used by Sage (or any other company other than my own) and am only going by the experiences of what I’ve seen and heard.
Update: Members of the Sage team have confirmed that “this is directionally close” to the process as used

First, all the requests are split into two areas:

  • Bug Fixes and improvements – defects where the product does not perform as designed or intended as well as compatibility with other new systems and usability
  • New Features and Enhancements – functional improvements to the actual design of the product

For each of these, a priority must be allocated. The priority would depend on a number of factors:

  • How many users would be affected by the bug or benefitted from the enhancement
  • If it’s a bug, it is data damaging or prevents the use of a primary function of the product
  • Also for bugs, can the issue be replicated in-house to determine the cause
  • For enhancements, would it just be a nice-to-have for current users or would it sell more product by being part of the decision making points of potential users
  • Is there a competitive need for the request – are other products in the market doing it
  • Are there manual workarounds or third-party products that could deal with the request now
  • How will the request integrate or interfere with current code and user interface design
  • How they fit into market trends/visions that they want to focus on
  • Usability and compatibility with adjacent products

Then, for each, a time-frame and cost must be determined. For this, a specification document must be created with much thought being given to looking at all the possible scenarios, data types and values that are considered likely. This is done by consulting users and developers for their input.

Finally they can decide which to approve now, delay for a future version or discard. Obviously, the higher the priority, the higher the allowable cost would be for it to be approved.

So, in order to have the best chance of getting your requests addressed, you should try and put it in terms to answer as many of the points mentioned.

I would write more, but the challenge limits us to 400 words….