Thanks in advance for beta testing my new podcast. I’d love to hear what you loved and what you think sucked. You can email me at victor (at) victorlombardi.com.
Subscribe to the audio version on iTunes
Watch the video on YouTube, or right here…
Thanks in advance for beta testing my new podcast. I’d love to hear what you loved and what you think sucked. You can email me at victor (at) victorlombardi.com.
Subscribe to the audio version on iTunes
Watch the video on YouTube, or right here…
Kevin Mercadante has a great review of Financial Engines on the Investor Junkie site. Here’s the key points I took away:
Founded in 1996, Financial Engines is a retirement plan advisory service for employees of participating employer retirement plans (which many online advisors work outside of).
They provide management services and advice so that either they can manage your plan, or you can do it yourself but armed with their information and input.
The service is made available through your employer plan, which is to say that it’s offered as an additional benefit — or in this case, a benefit within a benefit.
A very few employers make the service available to their staffs free of charge, but the range is between 0.20% and 0.60% of the value of your retirement portfolio, with the average being “just below 0.40%â€. Based on the average, the cost on a $100,000 401(k) plan would be just below $400 per year. This is the fee you will pay to Financial Engines while using their service. It does not include administrative fees paid to your account administrator, or transactions costs to trade and maintain securities and funds. As far as account minimums, there are none.
Services:
Analyze your retirement plan saving options
Consider expense ratios, sales loads, asset turnover, transaction costs, management style of individual fund investments, among other services
Provide you with a Progress Report showing your account balance, the potential value of your account when you retire, and the adjustments they’ve made to reflect your situation and market conditions
As you approach retirement, you get detailed Retirement Checkups with expert advisor representatives who can help you stay on track
Their Social Security Planner is a tool that can show you how to maximize your income from that source.
aka the father of modern portfolio theory
“Perhaps the most important job of a financial advisor is to get their clients in the right place on the efficient frontier in their portfolios,†he told me. “But their No. 2 job, a very close second, is to create portfolios that their clients are comfortable with. Advisors can create the best portfolios in the world, but they won’t really matter if the clients don’t stay in them.”
In other words, MPT and behavioral economics have to work together. And Moskowitz figured that out early…
“There was a big difference in my views about how and why to use mean variance analysis (that’s academic-speak for MPT) in my 1952 paper and in my ’59 paper. In the ’52 paper the only portfolio constraints I was concerned about were to avoid negative returns. But by 1959, I was concerned about [how investors would react to] the portfolio construction: For the comfort of the clients, we put constraints on ‘risky sounding stuff,’ such as junk bonds, etc. We knew that might dampen returns, but it was better than if they chicken out in a down market.â€
From an interview with Bob Clark.
“Policy-Based Financial Planning: Decision Rules for a Changing World†by Dave Yeske, managing director, and Elisa Buie, CEO of Yeske Buie. Based on their 2011 paper, Yeske and Buie provided a six-step process for creating effective financial planning policies for each client:
“Advising the Behavioral Investor: Lessons from the Real World†by Gregg Fisher, founder of Gerstein Fisher. “While he cited common investor mistakes such as failing to rebalance, chasing yield and underestimating the impact of inflation, he also explored the less talked about failure to consider a client’s income stream as an asset; one that requires at least as much—if not more—offsetting diversification than their other holdings.”
“His unconventional approach is also evident in the considerable body of research he cited debunking the advantage of dollar-cost averaging versus lump-sum investments. Fisher suggested that “sub-optimal†investment strategies can also be the best investment strategies. “Instead of debating [whether MPT or behavioral finance strategies are better], an investment advisor should borrow from both. The result will be an investment portfolio and strategy that may be suboptimal from an MPT standpoint, but may be the right approach for the investors. In other words, sometimes ‘the right portfolio’ isn’t the right portfolio.â€
He used an example that shows how “based on information about a client, as well as experience with other clients in similar situations, an advisor might conclude that this client would panic and sell equities at a major loss at the market bottom. As a financial advisor, the best case may be to recommend that this investor pay off their mortgage and student loans before investing in risky assets. Again, no financial optimizer would recommend this strategy.â€
“Post-Crisis Investor Behavior: Experience Matters,†by Joseph Rizzi, president of Macro Strategies LLC. “The financial crisis of 2008-2009 with its 50% drop in stock market value is seared into the collective investor memory—especially generation Y investors,†he wrote. “[Younger] investors are more focused on reacting to macro developments than asset fundamentals. The shift from ‘return on capital’ to ‘return of capital’ underlies the move away from equities into perceived lower risk fixed income by certain investor groups.â€
See also this interview with Harry Markowitz
* I haven’t read this book yet. I’m summarizing this book review. I do this so when I want to know more about this topic and find this post I know which book I should go to for more.
One reason I love bouldering is that it’s game-like. No matter how much experience a climber has, we’re all at a certain level with certain climbs (they’re actually called “problems”) that currently challenge us. It’s like playing a well-crafted video game: the levels you’ve finished are easy, the levels ahead of you are frustratingly hard, but the level you’re currently on is a good match of difficulty for your skill level; and you can feel the flow.
I recently started learning a new programming language and I find it similarly game-like. Every new technique is a new challenge. Every new algorithm is a new challenge. The easy stuff is boring, the crazy theoretically stuff is frustrating, but the next chapter in my book is just right.
And like video games, in bouldering these problems are codified. So I can say, “I can do all the V0’s in this gym, and I’m working on the V1’s” and other climbers know something about my abilities.* Codified problems exist elsewhere too. Here’s some to help people improve their skills playing Go.
I’d love to see graded problems for interaction design. They would make it fun to solve problems, alone or socially, and communicate to each other our level of ability. “But Victor,” you might say, “interaction design problems don’t have a defined solution like a boulder.” Actually the boulders don’t either. People can solve the same problem different ways, but there are rules everyone must follow that give the game useful constraints. As long as you follow the rules and get to the top you’ve solved the problem. Some climbers are more elegant than others, and the same would be true in interaction design.
* The Moonboard is like graded problem-meets-Github, a single wall with over 800 bouldering problems contributed by various route setters.
Pulling out some highlights of the Household Financial Planning Survey:
I recently decided to re-learn programming. Because I already know HTML and CSS the web is a fast prototyping environment for me, so JavaScript is the logical language for me to learn. Besides,
At first I tried learning from a traditional book, from CodeAcademy, and by reading online. But I was only spending 30 minutes a day on it, and nothing stuck. It’s like my guitar teacher told me when I was 14: “When you start, you need to practice at least an hour a day to train your brain to think this way, or it’s not going to work.”
Four days ago I bought the excellent Head First JavaScript Programming book and have been making my way through a chapter a day, obediantly doing all the exercises with a pencil in the book and in code on the computer.
It feels great. My brain is so happy to learn something new and useful. After day 2 I was able to bang out a simple prototype of an algorithm that was too painful to do in Excel. I wish I had done this sooner.
I’m at the point in my project where I need to prototype some software ideas. Doing it on the web is cheaper, simpler, and faster than prototyping a mobile app. And everything I need to do can be done on the front-end, for now. So I’m probably looking at JavaScript or Ruby on Rails, though there are other options.
I went looking to hire a programmer or a small firm to help me. I even wrote a simple spec to make the task official. But it turns out my task is not complicated enough to engage someone else.[1] And yet it’s beyond my HTML/CSS skills.
When I was young I taught myself BASIC on my Sinclair 1000, optimizing code to fit in 1K of memory. I kept those skills fresh in high school and college and even did a bit of Pascal work in grad school.
But that was a long time ago. Since then I’ve been busy learning about networks, then design, then business, then being a husband and father. Just about every year I would wonder if I should re-learn programming, if only to prototype my interaction design ideas. This often took the form of, “Should this be the year I learn Flash?” The good news is I didn’t spend a lot of time developing deep Flash expertise.
Why is 2014 any different? A few reasons:
So, it’s time to learn JavaScript. More on that choice in my next post.
[1] And all the developers I talk to want to differentiate based on services. I hear from a lot of people that want to brainstorm, to partner on ideas, to think about strategy and process, and to measure ROI. For once I’d love to hear someone say, “All we want to do is write solid code at a reasonable price.” return to text
Why We Fail is available in eBook form at O’Reilly and all the reviewers there gave me 5 stars! Yay!
Paul in Austin writes:
The case studies alone provide an very interesting read to anybody who has some interest in technology in general.
Each case study has been thoroughly researched with plenty of references. The author also provides video clips to help the reader visualize the user experience of the discussed products.
In addition to user interface developers or designers, product managers and architects will also benefit from the methods for avoiding future UX failures described in the second half of the book.
BOTTOM LINE Yes, I would recommend this to a friend
Ken in Hoboken writes:
Too many books focus on success but I feel the best way to learn is by studying failures.
Prior to reading “Why We Fail”, the only other book I read along the same lines was “Billion Dollar Lessons: What You Can Learn from the Most Inexcusable Business Failures of the Last 25 Years” by Carroll & Mui.
I am an engineer, not a designer, but I often consult on projects where no UX person is hired, forcing me to assume that role in some fashion. I found this book to provide great insights that I would not have otherwise considered.
For example, as an engineer, I focus on meeting the user requirements, but the case study on the failure of the Microsoft Zune music player (Chapter 5) demonstrates how much more powerful the user experience is over the feature set.
I found it an eye-opening revelation in Chapter 9 that Microsoft’s many expensive failures is due to its practice of sweeping mistakes under the rug and never sharing experiences with their product groups.
Chapter 7’s discussion on ethics is a valuable addition to the material.
I highly recommend this book.
BOTTOM LINE Yes, I would recommend this to a friend
I frequently design financial services, and having just rolled off a project took some time to reflect on trends I’ve noticed. Here’s the first three that came to mind:
I had a five-minute conversation with an angel investor last week and described the product I’m working on. His response: “Similar things are being done by bigger companies with giant marketing budgets, so you’ll need a very clever marketing idea to succeed. What is it?”
There was an uncomfortable pause. On one hand, I haven’t thought up any great marketing ideas yet and wondered if that was a hole in my plan. On the other hand, I was pretty sure this investor and I had very different perspectives on product development, but I didn’t have the language to succinctly express that gap.
I did understand what he meant. A few years ago I managed a large online dating service. We radically updated the design and added great features, but it was the online marketing that kept the revenue coming in. Why? I believe that while the design was good, the product wasn’t positioned to differentiate it from the competition. By contrast, if you design a product that’s different and more exciting than the competition, like the Anki DRIVE, there will be a lot more free media exposure and word of mouth to complement paid marketing.
My downfall, I think, is that I was trying to tell this investor about the product rather than show him. If my new and improved positioning is a result of product design, I need to show the product. For example, if I verbally described the Anki DRIVE as, “a racing game that combines an iOS app with physical race cars” that’s sounds mildly exciting. Watching the video is so much better…
As I write this there’s a group of about 15 developers and designers standing near my desk in a heated but constructive argument about how to check the design is right before the code heads off to QA.
Occasionally the dichotomy of agile vs. waterfall is raised, and sometimes “agile” is used as a euphemism for “flexible” as in, “well, there was an update in design document X, and we’re agile, so you should be able to integrate that.”
If there’s one thing I’ve learned from doing agile it’s that agile ain’t wishy washy, i.e. it’s not really some sort of flexibility nirvana. Any software development process relies on firm lines drawn around what, when, and how the work gets done. Otherwise, shit don’t get done.
Yes, agile is better at responding to change. But it is effective, somewhat counterintuitively, because it responds to change with a high degree of rigidity. For example, if the stories aren’t written in a way that makes it clear to developers how to code a feature and how to test it, it doesn’t get accepted into a sprint. Once stories are accepted into a sprint nothing else can start until the next sprint. And so on. When I first encountered all this rigidity I thought the developers were acting like self-involved prima donnas. Actually, they’re just enforcing the rules that make the process work.
Agile responds to change, not wishy washiness.
For over seven months I’ve been working with the good folks at Alexander Interactive on some ambitious work for MetLife. Here’s a peek into that work with a focus on process.
I’m the guy at the whiteboard in the Tokyo board room on page 73 :-)
A benefit of being a speaker at Failcon was getting an invitation to a talk hosted by Anit Guha of Orrick Legal. Here’s some of his wisdom that I noted down:
While I was researching my book Why We Fail: Learning from Experience Design Failures I spent some time reading about people’s experience with RealNetworks, particularly the RealPlayer, and wondering if they were worthy of inclusion in the book, particularly the don’t be evil chapter. At that point there was no smoking gun, no hard evidence that Real intentionally did the wrong thing.
But this week a story was published which confirmed my suspicions. It’s called The Graph That Changed Me. Here’s an excerpt:
One day my manager showed me a horrible graph. It was pretty simple: the graph was steady, then it dropped straight down, then after a short period, the line shot straight back up and stayed level again:
Artist’s rendering of why you probably don’t like RealPlayer much
“That’s what happens when we do the right thingâ€, he said while pointing at the drop, “and that’s how much money we lose. We tried it just to see how bad it was for our bottom line. And this is what the data tells us.â€â€œWow,†I said, taken aback. My employer clearly had two options: “do the right thing†or “be profitableâ€. That was the position they had maneuvered themselves into through a series of bad management decisions.
That “series of bad management decisions” may involve a slippery slope of subtle temptations and minor rationalizations, not one big bad decision to be evil. But having been there I know it’s all too easy to fall into the trap of binary thinking. You can hear it in that story:
two options: “do the right thing†or “be profitableâ€.
Design thinking is abductive, inventing new options to find new and better solutions to problems. In the universe of all possible businesses, were there more options than just “do the right thing†or “be profitableâ€? Of course. We just need to be willing to try harder, apply our creativity, and make “do the right thing and be profitable” two constraints of the design problem.