Pivots are a Trap(blog.thirdyearmba.com)
blog.thirdyearmba.com
Pivots are a Trap
http://blog.thirdyearmba.com/pivots-kill
21 comments
The word "pivot" is like "refactoring." It's so overused that it's mostly misused, and you can't rely on its meaning any more.
I'm curious, how is "refactoring" overused or misused?
To me, it's about cleaning up code in order to make it better-architected and (often) smaller, so there are less opportunities for bugs, and it is more extensible. Are there other uses I'm unaware of?
To me, it's about cleaning up code in order to make it better-architected and (often) smaller, so there are less opportunities for bugs, and it is more extensible. Are there other uses I'm unaware of?
The traditional definition of refactoring is making well-understood, deterministic transformation of code from one state to another in a way that provably has no effects on the behavior. For example, Extract Method or Inline Variable are refactorings that can be automated by your IDE and by definition will not break anything.
Nowadays people seem to use "refactoring" to mean "changing code without adding new front-facing features." This is bad as it causes large, scary changes to fall into the realm of "refactoring." Refactoring, if you want to live by its original definition, should be a relatively mindless, safe series of small well understood steps.
Nowadays people seem to use "refactoring" to mean "changing code without adding new front-facing features." This is bad as it causes large, scary changes to fall into the realm of "refactoring." Refactoring, if you want to live by its original definition, should be a relatively mindless, safe series of small well understood steps.
Interesting. So, taking a widget with CSS styling full of negative margins and redundant <div>'s and "!important"'s and font-sizes which overwrite each other five times... And cleaning it up so that each element and rule does exactly what it should be designed to do, in 1/5 of the number of CSS rules, and is now easily added to, but looks exactly the same in the end...
If that's not called refactoring, what is it supposed to be called? I would hate to use terms like "cleaning up code" or "improving code" because they're so horribly vague (they could be about merely changing tabs to spaces, or include adding whole new features).
Suggestions?
If that's not called refactoring, what is it supposed to be called? I would hate to use terms like "cleaning up code" or "improving code" because they're so horribly vague (they could be about merely changing tabs to spaces, or include adding whole new features).
Suggestions?
Honestly in that example I think you're probably safely within the classic definition, since its just a gap in tooling that makes it you can't make those types of transformations automatically in baby steps.
Here's an example of someone using it wrong: "We are going to refactor the API call to have 5 parameters instead of 4." The word they are looking for here is "change" or "extend", and they're falling back on "refactor" since they think it makes them sound smarter.
Here's an example of someone using it wrong: "We are going to refactor the API call to have 5 parameters instead of 4." The word they are looking for here is "change" or "extend", and they're falling back on "refactor" since they think it makes them sound smarter.
OK, now I get how people misuse it, I totally agree :)
>>The traditional definition of refactoring is making well-understood, deterministic transformation of code from one state to another in a way that provably has no effects on the behavior.
That is not incorrect but for it to be true refactoring you would have to add this:
You extract (or refactor) all the duplicate pieces of code that are performing the same functionality and merge them into (or replace them by) a single module.
That is what refactoring truly is.
That is not incorrect but for it to be true refactoring you would have to add this:
You extract (or refactor) all the duplicate pieces of code that are performing the same functionality and merge them into (or replace them by) a single module.
That is what refactoring truly is.
You've just made up your own definition of refactoring or worse taken it from wikipedia which is also just made up.
Refactoring all really started with Martin Fowler's book way, way, way before the IDE driven refactors were available and there are plenty of things that he describes in there that have no chance of being automated.
Where on earth you picked up your 'traditional definition' I do not know. I recommend reading Martin Fowler's book.
Refactoring all really started with Martin Fowler's book way, way, way before the IDE driven refactors were available and there are plenty of things that he describes in there that have no chance of being automated.
Where on earth you picked up your 'traditional definition' I do not know. I recommend reading Martin Fowler's book.
Our startup, bloc (www.bloc.io), pivoted four times in 8 months, and we're way happy with where we are now.
The vision, or core motivation, never did change though. There's a common thread through all four pivots. In fact the current product looks most similar to the very first. But it's different in important ways that weren't known during pivot 1.
Here's the full story http://jmtame.posterous.com/this-is-how-you-actually-teach-p...
The vision, or core motivation, never did change though. There's a common thread through all four pivots. In fact the current product looks most similar to the very first. But it's different in important ways that weren't known during pivot 1.
Here's the full story http://jmtame.posterous.com/this-is-how-you-actually-teach-p...
I think Jared is a smart guy and I respect him a lot. However, I think that both Niroka and Officehours.TV could have eventually worked out in some form (they both seemed like credible products when they came out). I think that the key missing ingredient was probably time and some iteration in the solution space (rather than an entirely new product). With that said, I'm glad that you guys found something that worked for you.
Speaking of a cofounder of Justin.tv, I'm not sure what you'd call TwitchTV other than a pivot and it seems to be working out well.
SocialCam as well. Definitely a pivot for us.
SocialCam as well. Definitely a pivot for us.
TwitchTV is a rebranding. Hell, you guys still use the Justin.tv domain for payment. By far the biggest audience on JustinTV were those interested in watching games, so you honed in on that. What's the difference between JustinTV and TwitchTV besides UI/visuals?
"A live video platform for the whole web" vs. "a social video layer for video games" are very different visions.
The most obvious difference? We have a partner program to help encourage an ecosystem of professional casters and players to form. We never would have built that for Justin.tv.
The most obvious difference? We have a partner program to help encourage an ecosystem of professional casters and players to form. We never would have built that for Justin.tv.
Well, the common thread is still distribution of video content...that to me sounds like the "vision" with attempting different strategies to accomplish it?
I agree with the spirit of this article. After having changed focus 3 times in the last year I realized that I wasn't giving each project enough time to develop. There were other good reasons for shifting direction, but lack of traction shouldn't have been a factor.
I believe that a common reason for changing direction early is that founders learn a lot about their problem in the first three months. Sometimes they learn that it's the wrong problem for them to tackle. It could still be a great business, but not a good fit for the founders. Prior research can reduce the chance of a "gotcha," but often you must interact with customers to really understand the problem. Yeah, customer dev techniques can speed this up, but it's a process that takes time regardless.
I believe that a common reason for changing direction early is that founders learn a lot about their problem in the first three months. Sometimes they learn that it's the wrong problem for them to tackle. It could still be a great business, but not a good fit for the founders. Prior research can reduce the chance of a "gotcha," but often you must interact with customers to really understand the problem. Yeah, customer dev techniques can speed this up, but it's a process that takes time regardless.
I think any story on Pivots deserve to have the story of the Fab Pivot
http://www.slideshare.net/fabulis/fab-2011-timeline
http://www.slideshare.net/fabulis/fab-2011-timeline
For our start-up we made a major pivot but it complements the original concept and even expanded it. If a pivot requires significant change in direction and scrapping major elements of your original idea then one really has to think hard before taking the next step.
I was kind of hoping that this was a story about employees of Pivotal (Pivots) causing trouble.
...and why do you want employees of Pivotal to be causing troubles?
One thing I learned is that while your vision should never change, you should keep trying different strategies until one works
And yet, the definition of a pivot, as given by the person that made the term widespread is very similar[1]:
A pivot is a change in strategy without a change in vision
And the author, at the end seems to actually agree with it:
But it's important to realize that taking different bites of the same apple is very different from biting into an entirely new pear or banana, and it seems like a lot of people are actually doing that
So I guess he is actually warning against one interpretation of a pivot, that is change in vision.
[1] http://www.marywisemandesign.com/pivot-change-the-strategy-n...