user centered design -> overlapping circles -> boundary selection -> platform strategies

9 Oct 2006 - 12:34am
7 years ago
1 reply
478 reads
Eugene Chen

Yes, this question was more about product definition than user interface
design. The user-interfaces would almost certainly quite different. Also, it
is not just a matter of two users A and B, but also C, D, E, etc. Using the
(hypothetical) example, the users would not just be Publishers and Authors,
but also Warehouse, Stores, Trucks, etc. as well as say Publishers from
indepent companies that could benefit from communicating with each other.
(The real example is from healthcare, but the details are gory)

I think the possible strategies are:
1 - Create an API so that software for Authors, Warehouses, Stores, and
Trucks can push and pull information our software for Publishers. In this
case, my main question is what sort of clout or incentive is necessary to
get existing vendors of software for Warehouses etc to care to support our
API? Or does it not matter?
2 - Create a free product and give it away to Warehouses etc., with the
benefit being improved communications with Publishers (would need to define
this better). But is it unfair that Publishers pay for the software, and
Warehouses get to use it for free? Also, even with a free product,
Warehouses may still resist using an additional system either due to
politics or just intertia.
3 - Identify the most popular software used by Warehouses, Stores, etc. and
explicitly integrate with them. We'd need to define the incentive for those
vendors in creating an open system. The problem is symmetrical in that
currently, Warehouse software vendors have created a half-baked system that
Publishers can use
4 - Get involved in a (drawn-out?) process to form or join an XML consortium
5 - Avoid connectivity features altogether and concentrate solely on an
inhouse product for Publishers
6 - Reorient the company to explicitly create a (possibly closed) platform
targeted at all the above customers. But that leads to the problem that Dave
alluded to--that there is no umbrella organization that can mandate that all
parties use the same product to communicate.
7 - Combinations of the above

Anyone have any experiences with any of the above strategies?


Eugene Chen | User Experience Research, Strategy and Design
mobile 415 336 1783 | fax 240 282 7452
web | aim peastulip | skype eugene-chen


Dave said:
3 Letters sorta say it all for me when you have a problem like this one.

"Application Program Interface"

Well, to be more specific, I think that people have the right intentions
with the "2 interface" solution, but having spent the last 6 years doing
enterprise software it is almost impossible for one end of the supply-chain
to force another end of the supply chain to use the same tools. Obvious
exceptions are Wal-Mart. Bur for us mere mortals the best we can really hope
for is to create the right "on-ramps" and "off-ramps" for the correctly
mapped data structures.

On 04/10/06, Eugene Chen <eugene at
<mailto:eugene at> > wrote:

The question is: on what principles to base the products
Strategically this leads to a question of which systems to
compete with
(subsume) vs. interface. And if to interace, then whether
should be one-way or two-way?


9 Oct 2006 - 1:20pm
Michael Micheletti

Hi Eugene,

The next may sound obvious, but it turns out to be really hard to execute
well. When you develop a partner network, you need to offer products or
services that benefit your partners. If you offer them a packaged product,
it will cost a lot of money and take training, integration, hop-on-board
time. If you offer them an API, someone needs to design/code/test/integrate
with it, and before they do this they need to learn how it all works -
typically a non-trivial task. I suggest that you figure out which of your
possible directions provide the greatest benefit for your customers and
partners and take that route, because your customers will be weighing
pain-vs-gain prior to purchase.

If you have the resources, you can try multiple approaches. Our company has
both finished products and an engine/API to offer partners, and each new
partnership is an extended courtship to determine the best approach.
Sometimes our new partner is a systems integrator with a lot of experience
and credibility in a single market, and they end up using our API to craft
solutions that surprise us. Other times a customer can work with our
products right out of the box. This dual approach has worked for us, at a
cost of a lot of hard work.

Michael Micheletti

On 10/8/06, Eugene Chen <eugene at> wrote:
> [Please voluntarily trim replies to include only relevant quoted
> material.]
> Anyone have any experiences with any of the above strategies?
> Eugene

Syndicate content Get the feed