web counter

Posts tagged as:

engineering

The Cranky PM on “Been There, Done That”

by The Cranky Product Manager on March 5, 2010

in Development

The following cartoon has been shamelessly republished from Shreyas Doshi’s excellent “How to Get that Next PM Job” presentation to the Silicon Valley Product Management Association.  Many years ago, during her first month at DysfunctoSoft, the Cranky Product Manager had this EXACT argument with the Engineering Manager for DysfunctoCrank:

Shreyas Doshi on Product Management

by Shreyas Doshi

It was years ago, but to this day the Cranky PM does not understand how that a-hole could take so LITTLE PRIDE  in his work that he would insist on shipping a product with the name misspelled.

At the time, the Cranky PM was shocked. But after years in the product management game, nothing surprises her anymore.

Rest assured, the Cranky PM won this battle.  The product was NOT renamed DysfucktoCrunk.

A little link love for Shreyas Doshi, for making the Cranky Product Manager chuckle just a little bit, through the tears of frustration:

{ 11 comments }

Guest Post: The Cranky Engineer Responds to a PRD

by The Cranky Product Manager on April 1, 2009

in Development,Guest Posts

Today we have a super-duper-uber-fantastic guest post from the Cranky Engineer, aka DGentry of codingrelic.geekhold.com. Check out his blog.  It’s WICKED AWESOME.

Also, you might recall that DGenery was the BIG WINNER of the Cranky Product Manager’s caption contest for the “7 Types of Engineers.” He won a fancy pants coffee mug.  AND HE LOVES IT.  Maybe YOU should buy a coffee mug too….

—————————-

From: Cranky Engineer #4
To: Product Manager #4
Date: Apr 1, 2009
Subject: Twitter reliability enhancement functional spec

Got your PRD about the 3G connectivity issues at the SXSW conference and the resulting drop in twitter volume, thanks. We couldn’t help but notice the lack of any actual requirements in the requirements document, but the main point seemed to be to “make it mo’ betta.” As mobile tower placement is subject to considerable regulation, we presume that the PRD is not calling for a build-out of a new national 3G network, but rather to eliminate dependencies on external factors beyond our control. Thus:

  • No dependency on mobile network capacity
  • No impact from density of surrounding buildings or obstacles
  • No necessity for the presence or absence of electricity.
  • No requirement for the user to own or know how to operate a computer

I think we’ve come up with a proposal which meets these requirements. The only remaining dependency is literacy. As we do not control the educational system in this country, this dependency may also need to be eliminated in a future version of this document.

Abstract of Proposal

Twitter usage is growing robustly, but is hampered by insufficient network capacity at heavily attended tech events such as SXSW and anywhere Steve Jobs gets up on a stage. Tweet volume from such events is lower than would be expected due to the connectivity issues.

It is proposed that designated drop zones be established at major tech events, where conference attendees can send and receive tweets. To avoid any dependency on telco infrastructure, tweets will be delivered to these TweetDrops by a robust and innovative mechanism.

1. Encoding

Each 140 character tweet is printed on a 5 mm wide paper strip, which is laminated and wrapped about the leg of a single carrier pigeon. The tweet is printed using a standard UPC barcode for ease of decoding at the remote end. The lamination is not necessary in theory, but in practice the messages often need to be wiped clean before processing (these are pigeons, after all).

2. Ordered Delivery

Conversations become difficult to follow if tweets are delivered out of order, but ordering is not guaranteed by the underlying network topology in this case. Therefore an 8 bit sequence number will be prepended to the barcode, which will be used to re-order pigeons arriving at the destination.

With 8 bits for sequencing information, only 256 pigeons can be launched at a time. The next wave of pigeons cannot be launched until it is certain that all members of the previous wave have left the system. To achieve acceptable throughput the natural lifespan of the pigeons cannot be used for this purpose.
Therefore, a small explosive device is fitted before launch to place a strong upper bound on the Time To Live (TTL) for that tweet. The next wave of tweets can be launched when the TTL for the previous wave has expired.

3. Loss detection

Due to the TTL mechanism employed for robust ordering it is possible that tweets will be dropped (or, more properly, exploded) in transit. To allow for retransmission an additional 8 bit acknowledgment field will be prepended to the barcode, and used to implement a sliding window protocol. (XXX Hang on, are we reinventing TCP here? Let’s have a sit-down about this before you forward it to PM, or we’ll end up rat-holing on this topic.)

Though lost tweets are expected to be a serious burden during initial deployment of this technology, it is believed that natural selection will result in a more reliable infrastructure as the less dependable population of pigeons is removed from the breeding stock by the TTL mechanism.

4. Operational Issues

The operations cost of this infrastructure is expected to be high, due to the need for replacement of pigeons whose TTL expired in transit. It is proposed that a breeding program be established in order to replenish capacity at minimal cost. This also nicely solves the problem of providing something for the pigeons to do between major tech events.

5. Direction of Future Work

The necessity of printing each tweet on a strip of paper and scanning the paper at the destination is a serious bottleneck in the communications path. A more efficient mechanism would be to download the tweets directly into the carrier pigeon via an existing Twitter API. Unfortunately the pigeons have strongly resisted attempts to implement any such mechanism.

The TTL mechanism can reasonably be expected to elicit a negative response from both animal rights activists and civil defense authorities, and should be considered only a temporary measure to reduce the time to market. A subsequent update to the infrastructure should investigate use of electromagnets to confuse the carrier’s natural homing instinct and send them somewhere where the tweet payload they carry will be harmless.

6. Security Considerations

No thorough analysis of the security of the carrier pigeon transport has been conducted. Because each pigeon will follow a different route to the destination owing to differences in wind currents, temperature gradients, and mood, it is unlikely that an attacker would be able to capture an entire conversation.
Additionally the TTL mechanism discourages interception of the pigeons in flight.

Encryption of the tweet payload is acceptable only if the pigeons can be guaranteed not to cross from within the United States to another sovereign nation, as such would violate US export and munitions laws.

7. References

[1] D. Waitzman, “A Standard for the Transmission of IP Datagrams on Avian Carriers,” RFC 1149, 1 April 1990.

{ 18 comments }

Why it doesn’t matter where Product Management lives in the organization

by The Cranky Product Manager on December 2, 2008

in The PM Profession

The Cranky Product Manager has read, and listened, and pondered, and debated, and bit her tongue over the years, as others have debated the proper place in the organization for the Product Management function.  Should it be in Engineering? Or in Marketing? Or in its own Products organization that reports directly to the CEO?

Not surprisingly, the answer depends on who you ask.

If you ask the CodeBoyz and CodeGrrlz, they generally think PM should be in Engineering. Because then the PMs could be forced to hang out in the Agile Tomb all day with the engineers. And because some CodeBoyz and CodeGrrlz think the PM should even pitch in and write some code now and then (a generally bad idea – see footnote 1).

If you ask the Marketing Weenies, well, naturally they want Product Management to be part of Marketing. Because then the Product Managers would somehow be more focused on customers and THE MARKET. Because, supposedly, you can’t focus on THE MARKET unless the letters M, A, R, K, E, and T are in your group’s name, in that order.

And if you ask many of illustrious luminaries and pundits that consult and train on the fine art of Product Management… well, they will all tell you that Product Management is such a strategic function that it should report directly to the CEO. Screw Engineering and Marketing!  We need a pipeline to the Big Cheese! And this is all fine and good, especially if you are the VP or Director of PM and want the ego boost of saying you report directly to the CEO. You could then give both the VP of Engineering and the VP of Marketing the finger if you so desire!

Anyway, for a long time the Cranky Product Manager has read these various arguments churning about in the blogo-sphere-iverse, and something about them — no matter what their theory or conclusion — pissed her off.  Just a little. And she couldn’t quite figure out why.

Until now. It’s the assumptions underlying this debate that irritate her.

The assumption is that if we sit in Engineering we’ll be too spineless and too tunnel-visioned to focus on the customer, market problems, issues for the field, the competition, or market positioning.  But if we sit in Marketing that we’ll be so focused on empty soundbites and website color schemes that we won’t be able to give Development detailed enough requirements, that we’ll conjure up product features that can’t possibly be built (a la Warp Drive), and that we’ll stare vacantly into space instead of considering technical extension points (i.e. APIs) for our products.

What a bunch of crap.

On the one hand, all these proselytizing and theorizing folk say that Product Managers need to be these gifted cross-functional leaders and act as CEOs of their products, but then on the other hand they don’t trust these Product Managers to do so, based on nothing more than where the Product Management function sits within the organization.

For the Cranky Product Manager, and for every decent product manager she has ever asked, EVERY SINGLE decision made as a product manager comes down to the following two questions:

1. Is this the right thing for my product?

2. Is this the best thing, out of all the possible “right” things, for my product?

GOOD product managers are obsessed with doing the RIGHT thing for their products – their bosses opinions be damned, and their bosses’ bosses opinions too.  They will fight tooth and nail to make the right things happen, to prioritize the activities that will move the needle the most (i.e. make the most money).  Whatever needs to be done to make the product a success.

This holistic, obsessive, determined, and pig-headed attitude is WHY good product managers are respected throughout their organizations.  It’s why people from different functions listen to them. It’s why they have credibility. It’s why they get stuff done. And, it’s why they are often “challenging” to manage, especially if your agenda includes items other than product success.

If good PMs were able to be easily pushed around by their VP’s latest political maneuverings, well they were probably not good PMs anyway. If this seems to be your challenge, well maybe you need to reconsider how you are evaluating your PMs – are you sure it’s based on their RESULTS and not their docility?

Anyway, possession of this do-it-right-and-do-it-best attitude has very little to do with WHERE the product manager sits in the organization.  It has everything to do with the personality, passion, and focus on results that each product manager brings to the job.

So instead of pondering this infernal, and pointless, organizational design question, perhaps we should focus on hiring the RIGHT types of people of Product Management jobs.

Read what others have said about this topic:

Footnotes:

1. Having product managers code is a dumb, dumb idea – trust the Cranky Product Manager. She’s a
fantabulous product manager but at this point has forgotten more about writing code than she ever learned. Like playing a musical instrument, coding is something you need to do on a regular basis to be anything but a crappy programmer.  Plus, it take the efforts of two mediocre programmers to undo the damage done by one crappy programmer. If a good PM has time to code often enough to not be completely crappy, he/she should probably instead spend that time looking for new market problems or doing competitive analysis.

{ 25 comments }