The Fiducial Mark

Now that 2010 has arrived, press releases and announcements for new “2010″ and “10″ version numbers are appearing with increasing frequency.

Why the change?  Why didn’t we see “2007″ version numbers a few years ago?  While there are a lot of 2010 versions coming out, an excellent post on “The Amazing World of Version Numbers” suggests the trend started way back in 1966 with Fortran 66 (although there are even earlier suggestions in the comments).  However, it didn’t register as a common naming practice until the release of Windows 95.

There are many methodologies for software version numbers.  Most of them operate under the premise that a big jump indicates a major release (e.g. moving from 8.0 to 9.0) while a minor increment indicates a minor release or perhaps even a maintenance release (e.g. 9.0 to 9.1).

The connotations surrounding “2010″ are plentiful: a new year, a new decade, and hopefully a new start after the biggest economic crisis of our time.  It’s an attractive reason to switch from an ordered number system to a date-based system.  It also represents a shift from engineering-based ordering to a marketing-based system.  While a 2010 label may give a product a fresh look, vendors switching to a date-based method should ensure the release matches expectations in terms of value for customers.  A minor update with little value repackaged as a “2010 Edition” has the potential to impact brand credibility.  On the flip-side, a new release packed full of valuable capabilities can warrant such a change and deliver some extra oomph during a new release launch.  Like many product management decisions, software version methodologies deserve careful consideration when planning a release.

Image Credit: Marcin Wichary

Yelp

The big news in the location-enabled social media biz this past week was a new update from Yelp.  As described in the TechCrunch post, the latest iPhone update from Yelp now allows check-ins.  This is a great development: check-ins allow people to share their location, connect, and say what the think about where they have checked in.  All of these things are good.  They allow us to to learn about particular spaces, share our own information and experiences about them, and provide a scheme that makes us feel good about “checking in.”  At first blush, these systems work fine…

But here’s the problem: locked-in environments.  The first location-based system I started using was Gowalla.  Why?  Because, like many other people, I don’t live in NYC or Los Angeles.  I live in a small city that wasn’t on the initial Foursquare list.  That’s fine: I started using Gowalla because it doesn’t care what city you’re in and allows you to create “spots” for anywhere.  Then, in a recent development, Foursquare allowed check-ins from any city.  OK – great news, and I started to try it out.  But then came Yelp – yet another system that allows me to check-in.  So I now have three systems that I can check-in on.  All of them will allow me to update Twitter or Facebook, but they are are still independent of each other.  I can’t add a “place” to Foursquare and Gowalla at the same time.  Choosing one system means ignoring another.  And by investing my time in one system, I’ll be less inclined to join into the next system that comes along allowing check-ins.

Sooooo, here’s calling for a universal check-in system.  Why is it that I have to choose between Yelp, Foursquare, or Gowalla?  Should I not be able to check in on a phone, and then that data gets shared with every location-based Social Media program I have subscribed to?  Interoperability will provide these products with features to differentiate on other than the ability to check-in.  And I suppose that’s the good thing about such a dynamic market space: greater competition and adoption will (hopefully) reward providers that support and promote interoperability.

I initially learned about MapAction during an Infoterra event in the UK about a year a half ago.  Impressed by their work, I’ve been following their activities ever since.  After reading they had a team en route to Haiti to assist in the humanitarian effort there, I took a look at their Field Guide to Humanitarian Mapping.  It’s an excellent introduction to mapping methodologies and GIS on a budget, with a heavy focus on concepts, data collection, and specific workflows.

Looking through their list of Open Source GIS applications, I thought it might be interesting to run through a small project: gather data for the affected parts of Haiti and think about data sources, workflows, and considerations in the field.

A few observations at the start, and then I’ll walk through the process I went through:

• Satellite Imagery: Very difficult to attain…  GeoEye has graciously released post-earthquake imagery, but it is still difficult to get the full resolution processed imagery (not an ungeoreferenced jpeg).  I think that remote sensing satellite operators would want to (a) process post-catastrophe imagery as quickly as possible, and (b) get the imagery into the public domain as soon as possible.  It’s great that we can see post-earthquake imagery as a network-link in Google Earth, but people on the ground are not necessarily going to have internet access.  I know we cannot rely on private companies to provide free data as a service, but I do believe there is a need to acquire imagery quickly and get it into the public domain.
• SRTM terrain data is a tremendous resource, but getting at the data can be tricky.  More on that below…
• OpenStreetMap only needs a one-word description: fantastic.  I read earlier today that there have been over 400 edits made to Haiti since the Earthquake.  People around the world are donating their time to help out the cause.  Another great thing about it is that it is extremely easy to check out data and then pull it into another application – more on that below.

The Goal

Nothing fancy: I just wanted to see how long it would take and if it would be challenging to pull together base mapping data and then view it all together.  No real geoprocessing, but just data acquisition and setup using open source software and publicly available data.  This would be a similar to real-world workflows one could use for in-the-field mapping applications.  With this software and data configuration, it would be possible to begin updating data in the field, performing analysis (e.g. slope analysis for areas that could have a greater potential for mudslides), and providing spatial resources to other humanitarian groups in the field.

Ingredients

Software: no better time to try out the new QuantumGIS version, 1.4.0 ‘enceladus.’  It’s a desktop GIS application, and the download and installation process is quick and easy.

Terrain: I decided to use SRTM as a terrain layer and primary base data layer.  Why?  Height information is valuable when combined with vector data.  For example: a road network layered on top of an orthophoto won’t tell you that the road is on a steep slope – and terrain will.

Vector data: OpenStreetMap data was an obvious choice here.  The coverage is pretty good, and it is also being rapidly updated.

Imagery: I thought about downloading some Landsat imagery but took a pass: for an urban application, the medium/low resolution publicly available data isn’t very helpful.  What’s needed is 0.5 meter resolution imagery from the latest generation of sensors, which isn’t yet public at the time of writing.

Process

Here’s a step-by-step overview of the process:

1) Download an install Quantum GIS from www.qgis.org.  No extra instructions needed: this is easy.

2) Find the appropriate SRTM data.  As much as I love working with it, this is my pet peeve with SRTM: it’s available from multiple host sites, with multiple processing levels, and it can be quite a challenge to find the data you need.  Maybe it’s just me, but every time I grab some I’m left thinking about how much easier it could be to access.  In this case I first went to the Consortium for Spatial Information site and downloaded the Google KML link, displayed below. 

Looking at the KML link identifies srtm_21_09 as the file required for Haiti.  Instead of navigating the maze of SRTM sites, I just Googled the filename, which took me here: http://collections.sdsc.edu/dac2/telascience/telascience_data/elevation/cgiar_srtm_v4/tiff/.  I then downloaded the appropriate TIF file.

3) Acquire vector data.  This was very straightforward: I’ve never tried to download or use OpenStreetMap data offline, but fortunately it is a fairly simple process.  I went to www.openstreetmap.org, zoomed into Port-au-Prince, and then selected the Export button at the top.  I exported the data in the OpenStreetMap XML format.

4) The next step is to start assembling the data in QGIS.  I launched the application and loaded the SRTM data.  If you’ve used a desktop GIS application before, QGIS is fairly intuitive.

The image above shows the SRTM data with a MinMax contrast stretch applied.

5) I had to use “Manage Plugins” and load the OpenStreetMap plugin prior to adding the OSM data (Plugins > OpenStreetMap > Load OSM from file).  Now it is possible to view the vectors over the terrain data.

6) Once the OSM data is loaded, we’re ready for field mapping.  Note that it is possible to query the OSM data as well.  The image below shows a query on a hospital, which is identified in the table on the right.

This workflow isn’t very sophisticated, but it does demonstrate the ability to get up and running relatively quickly.  SRTM and OSM data are both invaluable resources – ideal for humanitarian work in disaster areas.  As for the timing: if you know where to get the data, I think the simple example above could be completed in under an hour.  That includes software installation, data downloads, and then assembling the data in a GIS.

Most software vendors know that pricing can be a complex beast to tackle.  There are so many strategies and perspectives on pricing that you could fill a book.  Wait a second, there ARE books on pricing…  I recently came across “Software Product Management and Pricing” and gave it a read.  The latter part of the book has some valuable insights, and I particularly liked this one:

“Customer expectations must also be managed: it makes economic sense for a vendor to sacrifice some growth for a longer term commitment; it makes no sense for a vendor to cut price for a renewal of business with no growth.”

The quote pertains to enterprise offerings, where the authors discuss special bids for large accounts.  The point is that price negotiation and discounting strategies should take the larger context of the business relationship into consideration.  Sacrificing long-term revenue for short-term gain is something that happens all the time.  While it may help with quarterly results, it rarely pays off in the long run.

Full reference: Kittlaus, Hans-Bernd, and Peter Clough. Software Product Management and Pricing. Springer-Verlag New York Inc, 2009. Print.

Last October I reviewed Google’s new Building Maker application, and just recently I gave it another whirl.  While there are some new technical improvements (freeform polygons, new block options, and six new cities), it’s the concepts and implications of the system that continue to impress me…

3D Feature Extraction in Google's Building Maker

A few more thoughts on the implications:

• One of the best things about the system (and hopefully geospatial vendors are thinking about this as well) is that it’s 100% web-based.  All you require is a browser plug-in.  Compare this with other government or private mid to large-scale mapping efforts: these typically involve setting up local image servers in each office, and then shipping imagery around on hard drives.  Not ideal, but these are the realities when a single raw image can be 1GB in size.  While the geospatial market has a lot of image server solutions, not many organizations are delving into the imagery hosting/warehousing/serving business.  The current model is largely based on setting up your own infrastructure and hosting environment.
• I have a feeling this may represent the beginning a shift in how large/mid-scale mapping is performed.  While Building Maker is a  rudimentary toolset for 3D feature extraction, the idea of delivering browser based tools instead of desktop apps will open up a lot of opportunities.  For one thing, Building Maker is a great proof of concept for web-enabled mapping tools that don’t require thick desktop software installations.
• While a SOCET SET or PRO600 user may find Building Maker tools to be relatively basic, we shouldn’t underestimate the level of complexity in developing such a solution.  Mapping technology pre-dated software, and the commercial tools that are currently available have a high level of sophistication.  Hence, I don’t have any sort of expectation for a web-based replacement anytime soon.  The use of oblique imagery instead of creating some sort of stereo WMS viewer is a clever move by Google though.

Automatic Building Textures

Certainly interested in thoughts on this – and if you haven’t tried it yet, give Building Maker a whirl!

In yesterday’s post I outlined a few thoughts on how product launch processes vary between desktop and SaaS environments.  In writing the post, I noticed that there’s a massive volume of information available online pertaining to product launch planning.  Checking out several of the results, it seems like there are a lot of guidelines – and that’s a good thing.  Guidelines are great to follow, but the reality is that routinely following a checklist for software launches can get you into a rut quickly.  Every release is unique, and treating them as such at the start of the planning process can lead to better results.

Several years back I ran through the gamut of Product Management courses from Pragmatic Marketing.  As a new PM, they helped shape my views on the subject and as a consequence I still try to keep up with their newer material.  With regards to launches, I couldn’t put it better than Dave Daniels did in his “Ten Ways to Identify an Impending Product Launch Disaster” webinar.  Check out the webinar yourself, or the e-book below.  It definitely beats slogging through a lot of search results you’ll find online…

“Ten Ways to Identify an Impending Product Launch Disaster”

Planning software launches is a core element of Product Management, and typically requires a great deal of planning and preparation.  There many opinions on launch planning and instead of covering such a broad topic, I thought it would be interesting to write a few observations on differences between desktop software launches and software as a service (SaaS) releases.

Desktop software release cycles can be lengthy, and the QA and Acceptance Testing planning can be a challenge.  Operating systems, compatibility with other desktop software packages, as well as any proprietary format testing are all major considerations .  The time between major releases could be up to a year for products that I’ve been involved with, which may be interspersed with one or two minor releases.  Because of the lengthy release cycle, it always felt like there was a lot riding on a successful major release: when a year of effort is at stake you want to minimize the risks and ensure the launch delivery is smooth and successful.

With SaaS releases, the fundamentals of Product Management remain the same but the delivery mechanism is quite a bit different.  Here are a few observations, along with thoughts on how they can impact PMs:

Frequency: One characteristic of SaaS is a comparatively fast release cycle: any given individual release may not be as feature-rich, but significant releases may come every few weeks instead of every 6-12 months.  This means that launch plan components which used to be relatively sporadic need to be happening on an ongoing basis.  For example, a communication pipeline to sales teams, partners, and ultimately customers is something that needs to be revisited with a higher frequency.  For distributed teams, conducting internal webinars instead of or in addition to traditional events (e.g. in-person sales enablement training at an annual internal sales meeting) might be a practical method of delivering updates.

Quality Assurance: One of the perks of SaaS is the QA process, since operating system support is much less of a drain on velocity. Instead of having to corral beta customers on different operating systems and worrying about how your test matrix is exploding, you can focus on the fundamentals.  SaaS systems have different sorts of challenges (e.g. you don’t have to worry about up-time reporting in a desktop environment), but the ability to focus on core testing rather than running the same tests on X number of operating systems is a nice benefit.

Delivery:  Depending on the installation footprint, a lot of desktop packages need to be shipped out via DVD.  This represents planning, costs (and ensuring you get your quantity estimates right!), and an extra 4-6 weeks (shipping time) before customers can get their hands on the software.  This entire step is eliminated with SaaS, and from a user’s perspective the new features simply appear in the software upon release.  This presents a unique challenge…  Unlike the desktop software environment, customers cannot simply uninstall a shoddy release.  So the pressure for quality is high in a SaaS environment.  Any critical bugs that slipped through the cracks need to be dealt with immediately – but on the upshot deploying fixes is easier: they can be pushed out to all users at once.  This highlights on of the nice factors in delivery and customer care: when diagnosing an issue, you don’t need to query the customer on what version and patches they have installed and attempt to “find a needle in the haystack” of what could be causing a conflict.  All of your customers will be using the exact same version…

Marketing / Communication: Since SaaS users do not have to manually install new releases themselves, it’s important to think about communication.  I think the ideal is delivering an in-application notification system, but other channels such as blogging, email notifications, or direct contact by account managers are all viable options.  The challenge in the early feature planning is to ensure that new updates improve user experience and do not break or inhibit any existing workflows.

Documentation: A consideration here is that a traditional User Manual, training docs and other materials may become outdated rapidly or a burden to produce due to frequent release cycles.  I don’t have a silver bullet for this one, but I believe a positive direction would be a framework that allows you to plug in new material without a lot of overhead.  In practical terms this could mean digital documentation as opposed to print, and perhaps use of alternate mediums such as video content and short, concise quick reference guides instead of verbose documentation.  I’m definitely interested in other thoughts out there on this topic.

I’m enthusiastic about Product Management in a SaaS environment, and these are just a few initial observations.  Overall it seems to me like the principles of Product Management between SaaS and desktop products are quite similar, but timing and certain tactics can be different…

I’m very interested in insights and opinions on the topic: are there other considerations as well?

Thanks for stopping by The Fiducial Mark.  I’ve been blogging at fiducialmark.blogspot.com since early 2008, primarily on the topics of photogrammetry and mapping technologies.  After a recent break, I decided to start it back up again with a new focus.  You can read more about that in the About section, but in short I intend on writing more about product management, product development, and developments in areas such as geospatial, location-based and social media technologies.

Why “The Fiducial Mark?”  Well, I considered renaming the site or using a different domain, however the name has grown on me and I decided to stick with it.  A fiducial mark is a point of reference, which seems fitting for a technology blog.  You can see an example in the title image in the top of the page, and see here for a detailed description of the term.

I’m hoping to foster discussion in the areas mentioned above, since I believe they are all dynamic areas – and certainly poised for growth and change as we head into the new decade.