I strongly recommend GoodNotes for this use case. They do a better job than paper at all the "think" tasks like lassoing objects, handwriting in a zoom window, highlighting, etc.
To be clear, nobody tracks time, even for projects that are managed. The coordination I mentioned is about ensuring the right people are available to work together on the right things at the scale of days and weeks, not individual hours. Most of the hard work is making decisions about what to call 'done' versus where to keep iterating, and managing that over time so everyone experiences steady progress.
The app is the best experience. If you don't have the app or it's not supported on your platform, then you have the regular mobile web views to fall back on.
People in the tech world easily assume that upgrade = better. But that is only true if you feel underserved by the existing software you are running. Many customers out there in other fields don't have that feeling of being perpetually underserved that is common in places like Hacker News.
Native views and web views are good at different things.
Native is good for high fidelity interaction, animations, responding to gestures. However the native APIs are bad for designing "documents" -- that is, layouts where elements flow within a container and push each other around. That means that things that are extremely easy on the web can be painstaking in native UI without much upside.
Web views have limited interactivity, but they have other advantages:
* Faster iterations. You don't need to push a build when a webview changes.
* Document-style layout, as mentioned above.
* Higher density. We found it easier to show more information on the screen with HTML/CSS than the native controls. Looking at other apps out there makes me think it's an attribute of the medium, not just us.
* No need to sync data or duplicate logic. Sending HTML down the pipe is simple.
Finally yes, we get the multi-platform advantages because the web views are also served to people who hit the regular mobile web version of the app without any wrapper.
I don't claim that addressing anxiety is the only reason to say "Signup in 30 seconds." However, data about what converts better isn't a reason. Conversion data gives you correlations, not reasons for the correlations. I prefer to work from a theory of causality when I'm deciding what to put on the page.
You scale it by identifying which scopes of work are dependent on others and which scopes are independent. Any independent scopes can be designed, developed, and reviewed by small teams working at pace together, parallel to other teams. They key is how you break the work down into scopes, and how you see their interdependencies at a given moment and over time.
IMO that presents an opportunity: If 1:1 throughput isn't possible given the platform, what are the different ways we could approximate it? If we have to do design in advance, how much should we do, and which parts? All of these become useful challenges that can increase the role of feedback in your design when you take them on as such.
A product manager who doesn't understand implementations will not be able to negotiate when an implementation bears on interface design or scheduling decisions. Conflicts arise all the time between implementation, interface and schedule. To resolve them one has to understand all three.
This doesn't mean the product manager must understand code. It means there's a trade-off. If they don't understand software implementation, they need somebody on the team who does (what the article calls a "Technical Product Manager.") Adding another person is possible, but it hikes up the overhead and communication costs while dragging down the speed of development and decision-making.
The best case is a product manager who can understand a given implementation if and when it bears on decisions about what is possible in the interface or the production schedule. That person can make informed decisions because they understand all the factors.
It's fine that not everybody can do all three, but imo we should stay conscious of the trade-off and keep the bar high.
The only differences between conference sessions and workshops are a) length and b) number of people in the room. How you use an hour in front of a room of people is up to you. Conference sessions don't have to be limited to bullets on a slide or purely declarative knowledge.
I don't know about modesty, but it's correct that I was limiting myself to subjects that I know about. We have a shortage of truly great software designers and coders. So I think it's important that we shore up our methods for passing on knowledge and experience in these areas. If we treat it like somebody else's job, or academia's job, then we won't see the improvements that we want to see in conference quality, applicants for our job openings and so on.
My cocktail title at 37signals is "Product Manager," so whatever experiments are going on with management aren't completely past tense. I do UI design, work with the programmers, help design and dev work together and contribute strategy ideas to the partners.
Despite the cocktail title, there still isn't a clear "path of authority" or anything like that. The buck stops at the partners, and the rest of us function like a meritocracy. The ones with a track record or expertise on a given topic have a respected voice, and there is always opportunity for expertise to shift or widen over time. It's that fuzzy-edged quality to the role that makes it feel experimental for me.
I recommend going to a group to learn in person. It's easier to decide if you feel at home with a certain group of people than to judge books and theories about meditation when you don't have personal experience.
If you look for Buddhist groups, you'll find different kinds. The best way to avoid new-agey or flakey groups is to check their sources. Do they have a teacher who is a good example? Who was the teacher's teacher? Authentic Buddhist lineages of teacher and student trace themselves back for generations, and the teachers praise their teachers -- not themselves.
There are many authentic lineages. You'll find Japanese Zen schools which prefer a lot of discipline. There are also four Tibetan schools. The school of the Dalai Lama is called the Gelug school. It is the newest of the four schools and strongly emphasizes study and theory. The older Kagyu and Nyingma schools specialize in meditation and direct experience. In my experience, Kagyus tend to be more "learn by swimming" types and the Nyingma prefer a broad overview and more distance. I don't have experience with the fourth school, the Sakya.
I've meditated in the Kagyu school for six years now as part of the Diamond Way centers (http://www.lama-ole-nydahl.org/diamondway-buddhism/). Which group you find isn't important. The important thing if you want good results is that you find something authentic which fits you, and if it fits, stay with one thing without mixing. Different Buddhist schools use the same words for different things and different words for the same things, and it gets even more confusing if you mix Buddhist and non-Buddhist sources.
Some people have the notion that when you have a good idea, all you need is some money and time in order to be successful. It's not like that. You can have all the money in the world (look at big corps like Microsoft), and you can have great ideas, but unless you can execute, the money and ideas don't matter.
http://www.goodnotesapp.com (I'm not the maker, just a really big fan)