“A product shouldn’t be targeted at people or demographics; it should be targeted at the job people are trying to do.” @rjs on @quora
— alexander horré (@alexhorre) February 23, 2012
— Key differences between mainstream and early adopters
San Francisco native, now North East England. Coffee lover. Fashionable geek. Agile Projects at Thap Ltd. Startup Advisor. I host North East New Tech. Product evangelist at happiest. Rock climber. Check out more: about.me.
“A product shouldn’t be targeted at people or demographics; it should be targeted at the job people are trying to do.” @rjs on @quora
— alexander horré (@alexhorre) February 23, 2012
— Key differences between mainstream and early adopters

Clients love to email. When you have project governance in Basecamp, it’s very easy for team members to have correspondence in email with clients as well as Basecamp. Suddenly you have to check both apps to find the right answer. It can topple over very quickly. This is where Basecamp’s dropbox email comes in handy.
When you’re logged into your Basecamp, click your project and then click Messages tab. On right aside navigation, click the e-mail link to copy your dropbox email. Now take this email and create a contact in your Address Book and share it with your team. If you’re daring, create a mail rule to bbc this dropbox every time you email clients of this Basecamp project.
Now each time you email, Basecamp is fed the email correspondence. You might have to trial this out to see if clients need to add this too.

To me there is something more important than art and science. It’s in understanding how these two things intersect. For me, understanding the above makes for a better project and product manager. Great teams don’t hire for a role and skill set, they hire for the attitude and responsibility of delivering the whole product against quality. I think this is where most team’s can fail.
When a team fails due to a project or product under performing expectations. An example I use is when a website relaunch occurs when clearly its predecessor was better. Why does this happen? I surmise it’s due to a team lacking a product role, whom their duty is product integrity than the handful of assembled tasks attributed to a regular project and product manager.
This stems, in my view, from hiring. Teams fall victim to hiring for the role than hiring for the product. When you hire for the role, you inherit role resistance: preset patterns ‘x person’ has acquired that can go against the grain of building product regardless of any surface layering of ‘passion’ and ‘teamwork.’ You promote ‘over the wall’ mentality. At the end of the day, someone needs to own the product’s life during build, and that responsibility is the product manager, or project manager if their roles are intertwined.
A great product or project manager owns the product. Like in many agile articles, agile practices deteriorate without a clearly defined product owner. Project responsibility can occupy many seats, but the product owner guides project integrity with the delivery team, balancing delivery with business value. They must understand the art and science of domain language and behavior which defines a product’s requirements governed by business value:
This knowledge becomes tacit to the product owner. To have this member on your team takes an art and science quality. I think this person should split their skills 60/40 between business and technical. You merge the art of business case and the science of technical delivery. Together art and science guides product integrity, and a product or project manager of this capacity must take charge—but be hired in the first place. I surmise teams should hire this role to end the product paradox of hiring roles based on skill sets than product responsibilities.
If you don’t you end up with project managers managing tasks that don’t get delivered, and tasks delivered that don’t meet expectations. A critical sticking point to recognize is that tacit knowledge comes from contrast with the team. It won’t happen immediately, but soon enough your product owner can transform your build team into a well-oiled delivery machine.
__
Thanks to @imagemechanics for catching my typos and tweeting me about it. It was a late night.
The two apps in the wild that I speak of are @Oink and @Stamped. These two apps are of course incubated and launched from Silicon Valley, which over the last four years, thanks to Gavin Newsom, includes San Francisco. These two apps simply aren’t going to make it (crossing the chasm) because for two reasons: people don’t know what to share if there’s no limitations and the concept of shitty vs limited products.
Firstly: The limited vs shitty products conundrum. You need to ship early, and it shouldn’t be perfect. This mindset is easy to confuse and this very conundrum is any startup’s—located anywhere, with any sort of funding big or small—achilles heel. The problem with this mindset is people ship shitty products that aren’t focused, attempting to do too much inadequately overall that users simply can’t invest the time to extract its inherent value. You simply don’t understand us yet is the motto. Limited is simplified. You allow users a quality product that does one or two things very well nothing more.
With Oink the product should have been limited by geography. You rate items that can be discovered and visited through the UI reinforcing location around you therego building credibility in topics in your area. That’s the point of Oink, and they market it that way. Since Oink is mobile-only, a user should perceive the option to visit anything people rate. Oink is suppose to be a reviews-in-your-area-from your-friends you trust. Oink however breaks down by not limiting its product. You can rate anything, anywhere. This increases noise and deflates the signal users see as value. Suddenly my feed is full of meaningless ‘Oinks, mehs, likes’ of designer chairs on websites or the socks my friend put on this morning. As a user I have to walk through the mud, oinking, to find a gem. From my last tally, most people I know who used Oink stopped for this very reason.
Stamped gets this part right, almost: you either stamp it or you don’t. The product gives you less choice. It’s UI is more controlled allowing form and function to coexist from this giving the user more control and encouragement to share by the very existance of limitations. But Stamped gets away from itself when it markets ‘and more!’ It shouldn’t. Focus on books, shops, movies and things that people can visit and rate. Get people to discover new things in their city by approving ‘this item here is insane! You must try. I approve.’ Don’t encourage the options for users to begin rating their breakfast at their house.
To the heart of the matter: people simply don’t know what to share when new apps come along that build a vertical ontop of what people perceive ‘There’s Facebook for that.’ From this, people have an opportunity cost to decide what to share on what and from this, a shitty product won’t grow precisely by it offering too much too quickly. By allowing a limited product, that reinforces location-based items to rate within your geography than anything conceivably known to man—people will be encouraged to maintain that vertical in their life. If you try to do too much your UI must reinforce this plethora of choice. Most UIs that try immediately fail because your common user isn’t you. Your offering is diluted, people begin sharing meaningless things that are simply unattractive. You won’t cross over the value chasm.
Limiting is your only hope.

Working with a startup you learn which roles the team critically needs and which roles you don’t. You trim the fat. You want to have a focussed mindset. I spoke about this in @happiest’s latest blog post: Lean. One critical element the team needs that isn’t a role itself but is paramount is to understand that your product is foremost content.
When you look up the definition of content you get:
Something that is to be expressed through some medium, as speech, writing, or any of various arts
Substantive information or creative material viewed in contrast to its actual or potential manner of presentation
The meaning or significance [of something]
Now its other defintion:
Satisfied with what one is or has; not wanting more or anything else
Mentally or emotionally satisfied with things as they are
What this means is that a product foremost must explain itself through the interface a user interacts with before the product is even in their hands. This interface of course is the copy on the landing page, or the choices of terminology that structures key areas of interaction. For me it’s the blog—our product’s voice. What does your product do? Why does it do it? Content is your point of sale to convert uniques into regulars. To do that content must inform how the product is to be perceived and from that the user has a sense of convention with it. From this a user can then infer what the product can do next.
That’s why as a product evangelist my most important job is writing content that explains the mission: what is this product? Why are we here? What drives us? Where is the product going? A product needs a voice. If users first read and then do there should be no cognitive dissonance. The product preaches ‘x’ and after your interaction with said product your behavior should result in enjoying the product. You have a set of assumptions and the product should answer them or improve them. Yet there are those customers that may never enjoy what your product does—to evoke a principle of 37 Signals: ignore them, they’re startup killers.
Check out my current posts: http://hq.happie.st/author/alex/

I’m really proud about my latest talk I gave at @nenewtech. So I uploaded it to @speakerdeck. I attempt to draw a connection between how to best make products by distilling the ideals of rising popularity from Lean Startup by @ericries and Behaviour Driven Development by @tastapod.
One should learn, build, and measure a product that answers a problem through behaviour—how users interact with a product based on their known conventions and inference. I attempt to bridge a point that virtual and physical products all have interfaces we interact with by our direct feedback. This feedback is how we interpret how an interface behaves in accordance to our behaviour with it.
After my talk, I talked with some friends in the audience and we got to talking about product failures and how money relates as a huge factor. It costs more money to make better products. I disagreed. There will always be cheap products, but even expensive ones fail. By doing the right things right than the wrong things well, consumers will have better options than cheap and expensive but still shit.

I thought I’d share this discovery. I’m surprised I’ve seen no one talking about this yet. Simply set your current view in Twitter for Mac (e.g. replies, search topics, hashtags) and then ‘click-and-hold’ the Twitter for Mac icon. From the list select ‘Open in New Window’.

Apple is known for its design chops. Specifically this article regards Apple’s industrial design prowess. There have been articles already written about the importance of user experience around the Aesthetic Usability Effect.
As any fanboy would note, this would be a strength for Apple; however, this strength is also Apple’s biggest weakness. An example of this conundrum is the dock cable. Apple’s most recent design of this cable gives narrow prudence to its form more than its desired function—sometimes this distinction is a very thin line.
The resulting effects can be dire or sublime. Yet the resulting choice of the cable’s form in the dock cable’s current incarnation has dire effects than the sublime Apple is known for—and it shows. The tearing that occurs on the dock cable’s connectors has been evidently pointed out on Quora and Reddit. It’s time for Apple to officially come out with an update to rectify it.
The tearing that occurs on the dock cable’s end points occurs due to the constant friction that results from using the cable when connecting it either end, as well as twisting—normal usage. A prior version of the cable included a design that dissipated this friction; the newest design removed this for a ‘cleaner look’—a decision that is more form than function. A decision that may look beautiful but results in quickly-worn-out cables.
Apple’s warranty will replace these cables without question. Yet when the warranty runs out, Apple will refuse to replace them. However when the result is the same for every single person in the World—regardless of being within warranty—the cable’s propensity to easily and rather quickly tear at its ends—soon becomes a matter of legality. The product is faulty.
In California and the rest of the United States there is a lemon law where regardless of warranty the consumer is protected from faulty industrial designs and more. A consumer is protected from products that continue to fail in the same way. If the product fails the same way three times in a row, it’s considered a lemon. The consumer is legally guaranteed to be assisted and compensated.
I’ve since gone through the latest and greatest of iPods and iPhones, the result is always the same: the dock cable fails, tearing no matter how careful you are with it. Yet Apple will refuse if out of warranty.
Apple: When you are mandated as the best in industrial design, you are also expected to be the best. You’re failing at this. As Apple continues to become more mainstream and undisputed in the market, consumers become more knowledgeable and eventually hold you accountable, so shape up.