Mobile Rehash

by Dominique Jost

November 29, 2013 at 2:02pm
0 notes

Mobile interaction models

Benedict Evans:

So, we can actually have a pretty limited idea of what the dominant interaction models will be in 5 years.

There is a dream, of course, that all these nasty choices and options will go away and we can go back to the nice, simple, limited web, but that doesn’t seem very likely just yet.

(Source: ben-evans.com)

October 29, 2013 at 8:14am
0 notes

Ryan Singer (@rjs) on Software Management Techniques, Smart Teams and Scoping

September 24, 2013 at 12:54pm
0 notes

What Clayton Christensen Got Wrong in his Theory of Low-End Disruption

Christensen¹s theory is based on examples drawn from buying decisions made by businesses, not consumers. The reason this matters is that the theory of low-end disruption presumes:

  • Buyers are rational
  • Every attribute that matters can be documented and measured
  • Modular providers can become good enough on all the attributes that matter to the buyers

All three of the assumptions fail in the consumer market, and this, ultimately, is why Christensen¹s theory fails as well.

The framework that makes the most sense for the consumer market comes from another Harvard professor, Michael Porte: http://en.wikipedia.org/wiki/Porter’s_generic_strategies

(Source: stratechery.com)

August 30, 2013 at 10:44am
0 notes

How to work with engineers, PMs and designers

How to work with engineers: a cheat sheet for designers

https://medium.com/the-year-of-the-looking-glass/a3163ff1eced

The best way to ensure designs are implemented as intended is to work extremely closely with the engineer.

How to work with designers: a cheat sheet for engineers and PMs

https://medium.com/the-year-of-the-looking-glass/6c975dede146

The most direct path to a designer’s heart is to care about the details.

How to work with PMs: a cheat sheet for designers

https://medium.com/the-year-of-the-looking-glass/3e852d5eccf5

Your job will be easier if you treat your PM as a partner and a resource, not a taskmaster.

July 22, 2013 at 1:23pm
0 notes

Transitioning To a Mobile Centric World

Bill Gurley:

  1. Design takes on a greater role.
  2. Feature depth is inherently limited.
  3. Development complexity is a reality as we transition.
  4. HTML5 is a head-fake.
  5. SEO non-presence is hugely consequential.
  6. The core concept of “search” is in transition.
  7. A locked-in mobile application user is worth more than a desktop user.
  8. Customer acquisition techniques are shifting.
  9. Payment could be a new platform battleground.
  10. The platforms are still evolving.

(Source: abovethecrowd.com)

July 19, 2013 at 9:18am
0 notes

Khan Academy Development

  • Shipping beats perfection.
  • Be open. Share your work.
  • Anybody can fix anything.

(Source: sites.google.com)

July 12, 2013 at 8:27am
1 note

Be a great product leader

Adam Nash:

In the end, product managers ship, and that means that product managers cover whatever gaps in the process that need to be covered. Sometimes they author content. Sometimes they cover holes in design. Sometimes they are QA. Sometimes they do PR. Anything that needs to be done to make the product successful they do, within the limits of human capability.

(Source: blog.adamnash.com)

8:24am
1 note

We are Product Managers

Satya Patel:

We take time to reflect. We don’t fear failure. We strive to improve.

We are Product Managers.

(Source: venturegeneratedcontent.com)

July 9, 2013 at 8:31am
0 notes

The apps that get featured on the iOS App Store

Research showing the kinds of apps that get features on the iTunes App Store home page for different countries around the world. by Dave Addey.

(Source: daveaddey.com)

July 8, 2013 at 1:33pm
0 notes

The one cost engineers and product managers don’t consider

Kris Gale, VP Engineering at Yammer, on the cost of complexity

I believe good engineering is about finding the most cost-effective solution to a problem, whether that cost is measured in dollars, hours, morale or lost opportunities. Everyone in business knows this intuitively, but some costs are less obvious than others.

Among the most dangerously unconsidered costs is what I’ve been calling complexity cost. Complexity cost is the debt you accrue by complicating features or technology in order to solve problems. An application that does twenty things is more difficult to refactor than an application that does one thing, so changes to its code will take longer.

In software engineering, complexity cost is introduced in both product design and implementation. Embrace simplicity in your product and in your code. The value is in what gets used, not what gets built.

(Source: firstround.com)